[Bug ld/23906] LD Bug : Undocumented exit status 253

[davidledger at live dot com.au]

https://sourceware.org/bugzilla/show_bug.cgi?id=23906

--- Comment #11 from David Ledger <davidledger at live dot com.au> ---
Do you have a GitLab account, I can give you access to the actual repo, I
converted it to a cmake project.
Its a private repo so I’ll need to invite you.

You’ll need to change CMake/Toolchain.cmake, there is a windows specific folder
and your version of arm-none-eabi is likely in a different path to my Linux
build:
set(TOOCHAIN_INC_DIR "C:/Program Files (x86)/GNU Tools ARM Embedded/7
2018-q2-update/arm-none-eabi/include")
set(TOOCHAIN_LIB_DIR "C:/Program Files (x86)/GNU Tools ARM Embedded/7
2018-q2-update/arm-none-eabi/lib")
Cmake will use the wrong libs if you don’t change that line to the correct
path.

You can remove the error or not by enabling the //#define USE_SIZETEST macro in
include/library/SCPI.hpp.
The file is a bit messy I’ve been messing around with it for a while trying to
get past the linker error.

I don’t know how to make it run from within GDB. I don’t know how to intercept
CMakes call to ld.exe
I have moved the project to Linux, attempted to build it there, no change.
Issue still occurs but with a different error message:
“ld terminated with signal 11 (Segmentation fault), core dumped compilation
terminated.”

[cid:image001.png@01D448F4.339F3940]

David Ledger - Electronics Design Engineer
www.eevblog.com<http://www.eevblog.com>

 Skype: david.j.ledger



From: tnfchris at sourceware dot org<mailto:address@hidden>
Sent: Tuesday, 11 December 2018 12:18 AM
Subject: [Bug ld/23906] LD Bug : Undocumented exit status 253

https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceware.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D23906&amp;data=02%7C01%7C%7C909d0ab35efd4d1de76e08d65ea1f9a1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636800447101809438&amp;sdata=pxfCPjasyw3h%2FveW519CoX8Cqcaedi0V4TCkGnC2aqs%3D&amp;reserved=0

Tamar Christina <tnfchris at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tnfchris at sourceware dot org

--- Comment #10 from Tamar Christina <tnfchris at sourceware dot org> ---
Hi David,

I have tried to reproduce this today using the files you provided and it seems
to work fine.

C:\Users\tamar\Desktop\binutils\Release>arm-none-eabi-g++ -mcpu=cortex-m0
-march=armv6-m -mthumb -Os -fmessage-length=0 -ffunction-sections
-fdata-sections -ffreestanding -Wall -Wextra  -g -T "../ldscripts/mem.ld" -T
"../ldscripts/sections.ld" -T "../ldscripts/libs.ld" -nostartfiles -Xlinker
--gc-sections -L"../ldscripts" <snip>

GNU ld (GNU Tools for Arm Embedded Processors 7-2018-q2-update) 2.30.0.20180329
PS C:\Users\tamar\Desktop\binutils\Release> echo $LASTEXITCODE
0
PS C:\Users\tamar\Desktop\binutils\Release> dir *.elf


    Directory: C:\Users\tamar\Desktop\binutils\Release


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       12/10/2018   1:05 PM        6117116 uSupply Firmware V1_0.elf

Since gdb doesn't support coredumps on Windows, can you instead get a windbg
dump using procdump?
https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fsysinternals%2Fdownloads%2Fprocdump&amp;data=02%7C01%7C%7C909d0ab35efd4d1de76e08d65ea1f9a1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636800447101809438&amp;sdata=bs1xpyFAv8PCUtO0q7z4OWkJzfriM5yN0Wax8tj8QzM%3D&amp;reserved=0

using

procdump.exe -t -ma -e 1 -x . <prog+args>

which will dump the entire process memory.

Unfortunately procdump can't dump child processes so you'll have to isolate the
linker command from g++,

you can do this by running g++ with -Wl,-debug -save-temps as Nick mentioned
before.

--
You are receiving this mail because:
You reported the bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.