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:sourceware-bugzi...@sourceware.org> 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&data=02%7C01%7C%7C909d0ab35efd4d1de76e08d65ea1f9a1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636800447101809438&sdata=pxfCPjasyw3h%2FveW519CoX8Cqcaedi0V4TCkGnC2aqs%3D&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&data=02%7C01%7C%7C909d0ab35efd4d1de76e08d65ea1f9a1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636800447101809438&sdata=bs1xpyFAv8PCUtO0q7z4OWkJzfriM5yN0Wax8tj8QzM%3D&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. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
