[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: davidledger at live dot com.au
Subject: [Bug ld/23906] LD Bug : Undocumented exit status 253
Date: Wed, 12 Dec 2018 05:34:21 +0000


--- 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
set(TOOCHAIN_INC_DIR "C:/Program Files (x86)/GNU Tools ARM Embedded/7
set(TOOCHAIN_LIB_DIR "C:/Program Files (x86)/GNU Tools ARM Embedded/7
Cmake will use the wrong libs if you don’t change that line to the correct

You can remove the error or not by enabling the //#define USE_SIZETEST macro in
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


David Ledger - Electronics Design Engineer

 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


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)
PS C:\Users\tamar\Desktop\binutils\Release> echo $LASTEXITCODE
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?


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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]