Hello, For the last 3 days I’ve been trying to work around a bug in the ld.exe linker. I’m hoping I can resolve the issue. The project is a C++ project for the ArmV6-m, cortexM0, I’m using “GNU ARM Cross C++ Linker”. The issue is that as I enable various sections of the code the linker suddenly stops working and begins reporting the following error: collect2.exe: error: ld returned 253 exit status There is no additional helpful messages, nothing useful comes out of verbose either. This is the information that comes out of the linker on verbose: Invoking: GNU ARM Cross C++ Linker arm-none-eabi-g++ -mcpu=cortex-m0 -march=armv6-m -mthumb -Os -fmessage-length=0 -ffreestanding -flto -Wall -Wextra -T "../ldscripts/mem.ld" -T "../ldscripts/sections.ld" -T "../ldscripts/libs.ld" -nostartfiles -Xlinker --gc-sections -L"../ldscripts" -Wl,-Map,"uSupply Firmware V1_0.map" --specs=nano.specs -v -o "uSupply Firmware V1_0.elf" ./system/src/stm32f0-stdperiph/stm32f0xx_adc.o ./system/src/stm32f0-stdperiph/stm32f0xx_can.o ./system/src/stm32f0-stdperiph/stm32f0xx_cec.o ./system/src/stm32f0-stdperiph/stm32f0xx_comp.o ./system/src/stm32f0-stdperiph/stm32f0xx_crc.o ./system/src/stm32f0-stdperiph/stm32f0xx_crs.o ./system/src/stm32f0-stdperiph/stm32f0xx_dac.o ./system/src/stm32f0-stdperiph/stm32f0xx_dbgmcu.o ./system/src/stm32f0-stdperiph/stm32f0xx_dma.o ./system/src/stm32f0-stdperiph/stm32f0xx_exti.o ./system/src/stm32f0-stdperiph/stm32f0xx_flash.o ./system/src/stm32f0-stdperiph/stm32f0xx_gpio.o ./system/src/stm32f0-stdperiph/stm32f0xx_i2c.o ./system/src/stm32f0-stdperiph/stm32f0xx_iwdg.o ./system/src/stm32f0-stdperiph/stm32f0xx_misc.o ./system/src/stm32f0-stdperiph/stm32f0xx_pwr.o ./system/src/stm32f0-stdperiph/stm32f0xx_rcc.o ./system/src/stm32f0-stdperiph/stm32f0xx_rtc.o ./system/src/stm32f0-stdperiph/stm32f0xx_spi.o ./system/src/stm32f0-stdperiph/stm32f0xx_syscfg.o ./system/src/stm32f0-stdperiph/stm32f0xx_tim.o ./system/src/stm32f0-stdperiph/stm32f0xx_usart.o ./system/src/stm32f0-stdperiph/stm32f0xx_wwdg.o ./system/src/newlib/_cxx.o ./system/src/newlib/_exit.o ./system/src/newlib/_sbrk.o ./system/src/newlib/_startup.o ./system/src/newlib/_syscalls.o ./system/src/newlib/assert.o ./system/src/diag/Trace.o ./system/src/diag/trace_impl.o ./system/src/cortexm/_initialize_hardware.o ./system/src/cortexm/_reset_hardware.o ./system/src/cortexm/exception_handlers.o ./system/src/cmsis/system_stm32f0xx.o ./system/src/cmsis/vectors_stm32f0xx.o ./src/peripherals/Interrupt.o ./src/_write.o ./src/main.o Using built-in specs. Reading specs from c:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib/nano.specs rename spec link to nano_link rename spec link_gcc_c_sequence to nano_link_gcc_c_sequence rename spec cpp_unique_options to nano_cpp_unique_options COLLECT_GCC=arm-none-eabi-g++ COLLECT_LTO_WRAPPER=c:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../lib/gcc/arm-none-eabi/7.2.1/lto-wrapper.exe Target: arm-none-eabi Configured with: /Host/Work/arm-none-eabi-gcc-7.2.1-1.1/gcc/configure --prefix=/Host/Work/arm-none-eabi-gcc-7.2.1-1.1/install/win64/arm-none-eabi-gcc --libexecdir=/Host/Work/arm-none-eabi-gcc-7.2.1-1.1/install/win64/arm-none-eabi-gcc/lib --infodir=/Host/Work/arm-none-eabi-gcc-7.2.1-1.1/install/win64/arm-none-eabi-gcc/share/doc/info --mandir=/Host/Work/arm-none-eabi-gcc-7.2.1-1.1/install/win64/arm-none-eabi-gcc/share/doc/man --htmldir=/Host/Work/arm-none-eabi-gcc-7.2.1-1.1/install/win64/arm-none-eabi-gcc/share/doc/html --pdfdir=/Host/Work/arm-none-eabi-gcc-7.2.1-1.1/install/win64/arm-none-eabi-gcc/share/doc/pdf --build=x86_64-unknown-linux-gnu --host=x86_64-w64-mingw32 --target=arm-none-eabi --with-pkgversion='GNU MCU Eclipse ARM Embedded GCC\x2C 64-bits' --enable-languages=c,c++ --enable-mingw-wildcard --enable-plugins --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-newlib --with-headers=yes --with-python-dir=share/gcc-arm-none-eabi --with-sysroot=/Host/Work/arm-none-eabi-gcc-7.2.1-1.1/install/win64/arm-none-eabi-gcc/arm-none-eabi --with-multilib-list=rmprofile --disable-rpath --disable-build-format-warnings --with-system-zlib Thread model: single gcc version 7.2.1 20170904 (release) [ARM/embedded-7-branch revision 255204] (GNU MCU Eclipse ARM Embedded GCC, 64-bits) COMPILER_PATH=c:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../lib/gcc/arm-none-eabi/7.2.1/;c:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../lib/gcc/;c:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ LIBRARY_PATH=c:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../lib/gcc/arm-none-eabi/7.2.1/thumb/v6-m/;c:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib/thumb/v6-m/;c:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../arm-none-eabi/lib/thumb/v6-m/;c:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../lib/gcc/arm-none-eabi/7.2.1/;c:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../lib/gcc/;c:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib/;c:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../arm-none-eabi/lib/ COLLECT_GCC_OPTIONS='-mcpu=cortex-m0' '-march=armv6-m' '-mthumb' '-Os' '-fmessage-length=0' '-ffreestanding' '-flto' '-Wall' '-Wextra' '-T' '../ldscripts/mem.ld' '-T' '../ldscripts/sections.ld' '-T' '../ldscripts/libs.ld' '-nostartfiles' '-L../ldscripts' '-specs=nano.specs' '-v' '-o' 'uSupply Firmware V1_0.elf' c:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../lib/gcc/arm-none-eabi/7.2.1/collect2.exe -flto --sysroot=c:\users\david\appdata\roaming\xpacks\@gnu-mcu-eclipse\arm-none-eabi-gcc\7.2.1-1.1.5\.content\bin\../arm-none-eabi -X -o uSupply Firmware V1_0.elf -L../ldscripts -Lc:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../lib/gcc/arm-none-eabi/7.2.1/thumb/v6-m -Lc:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib/thumb/v6-m -Lc:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../arm-none-eabi/lib/thumb/v6-m -Lc:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../lib/gcc/arm-none-eabi/7.2.1 -Lc:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../lib/gcc -Lc:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib -Lc:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../arm-none-eabi/lib --gc-sections -Map uSupply Firmware V1_0.map ./system/src/stm32f0-stdperiph/stm32f0xx_adc.o ./system/src/stm32f0-stdperiph/stm32f0xx_can.o ./system/src/stm32f0-stdperiph/stm32f0xx_cec.o ./system/src/stm32f0-stdperiph/stm32f0xx_comp.o ./system/src/stm32f0-stdperiph/stm32f0xx_crc.o ./system/src/stm32f0-stdperiph/stm32f0xx_crs.o ./system/src/stm32f0-stdperiph/stm32f0xx_dac.o ./system/src/stm32f0-stdperiph/stm32f0xx_dbgmcu.o ./system/src/stm32f0-stdperiph/stm32f0xx_dma.o ./system/src/stm32f0-stdperiph/stm32f0xx_exti.o ./system/src/stm32f0-stdperiph/stm32f0xx_flash.o ./system/src/stm32f0-stdperiph/stm32f0xx_gpio.o ./system/src/stm32f0-stdperiph/stm32f0xx_i2c.o ./system/src/stm32f0-stdperiph/stm32f0xx_iwdg.o ./system/src/stm32f0-stdperiph/stm32f0xx_misc.o ./system/src/stm32f0-stdperiph/stm32f0xx_pwr.o ./system/src/stm32f0-stdperiph/stm32f0xx_rcc.o ./system/src/stm32f0-stdperiph/stm32f0xx_rtc.o ./system/src/stm32f0-stdperiph/stm32f0xx_spi.o ./system/src/stm32f0-stdperiph/stm32f0xx_syscfg.o ./system/src/stm32f0-stdperiph/stm32f0xx_tim.o ./system/src/stm32f0-stdperiph/stm32f0xx_usart.o ./system/src/stm32f0-stdperiph/stm32f0xx_wwdg.o ./system/src/newlib/_cxx.o ./system/src/newlib/_exit.o ./system/src/newlib/_sbrk.o ./system/src/newlib/_startup.o ./system/src/newlib/_syscalls.o ./system/src/newlib/assert.o ./system/src/diag/Trace.o ./system/src/diag/trace_impl.o ./system/src/cortexm/_initialize_hardware.o ./system/src/cortexm/_reset_hardware.o ./system/src/cortexm/exception_handlers.o ./system/src/cmsis/system_stm32f0xx.o ./system/src/cmsis/vectors_stm32f0xx.o ./src/peripherals/Interrupt.o ./src/_write.o ./src/main.o -lstdc++_nano -lm --start-group -lgcc -lc_nano --end-group --start-group -lgcc -lc_nano --end-group -T ../ldscripts/mem.ld -T ../ldscripts/sections.ld -T ../ldscripts/libs.ld collect2.exe: error: ld returned 253 exit status make: *** [makefile:65: uSupply Firmware V1_0.elf] Error 1 The map file appears to be cut off mid way through printing type information (it seems to crash half way, maybe the type name simply is too long). Notice that it cuts out entirely half way through an incomplete type, in the middle of the word no less: .text._ZNK7General6Parser6StatesIJNS0_4SCPI3EndINS2_15CommandInternalINS0_5ChainIJRKNS0_7KeywordILj5ELj3EEERKNS0_8OptionalINS0_8RequiredILj3EEEEEEEEJNS2_4NoneILj0EEENS2_5BlankILj0EEEEEEZNS2_7CommandISG_SI_SK_ZNS2_4SCPIIN11Electronics6System6SystemENSP_5CommsEEEKDaRT_RT0_EUlST_E7_EEDaOST_OSV_OT1_OT2_EUlSY_E_EENS3_ISL_ZNSM_ISG_SI_SK_ZNSN_ISQ_SR_EESS_SU_SW_EUlST_E8_EEDaSY_SZ_S11_S13_EUlSY_E_EENS3_INS4_INS5_IJRKNS6_ILj4ELj2EEESF_EEEJSI_SK_EEEZNSM_IS1C_SI_SK_ZNSN_ISQ_SR_EESS_SU_SW_EUlST_E9_EEDaSY_SZ_S11_S13_EUlSY_E_EENS3_INS4_INS5_IJRKNS6_ILj5ELj2EEESF_EEEJSI_SK_EEEZNSM_IS1K_SI_SK_ZNSN_ISQ_SR_EESS_SU_SW_EUlST_E10_EEDaSY_SZ_S11_S13_EUlSY_E_EENS6_ILj5ELj4EEENSB_ILj5EEES1Q_S1Q_S1Q_S1Q_S1Q_S1Q_S1Q_EE3RunIJLj0ELj1ELj2ELj3ELj4ELj5ELj6ELj7ELj8ELj9ELj10ELj11ELj12EELj256EEEDaSt16integer_sequenceIjJXspT_EEERKSt5arrayIcXT0_EEj 0x0000000008009fdc 0xca ./src/main.o 0x0000000008009fdc auto General::Parser::States<General::Parser::SCPI::End<General::Parser::SCPI::CommandInternal<General::Parser::Chain<General::Parser::Keyword<5u, 3u> const&, General::Parser::Optional<General::Parser::Required<3u> > const&>, General::Parser::SCPI::None<0u>, General::Parser::SCPI::Blank<0u> >, auto General::Parser::SCPI::Command<General::Parser::Chain<General::Parser::Keyword<5u, 3u> const&, General::Parser::Optional<General::Parser::Required<3u> > const&>, General::Parser::SCPI::None<0u>, General::Parser::SCPI::Blank<0u>, auto const General::Parser::SCPI::SCPI<Electronics::System::System, Electronics::System::Comms>(Electronics::System::System&, Electronics::System::Comms&)::{lambda(auto:1)#9}>(Electronics::System::System&&, Electronics::System::Comms&&, General::Parser::SCPI::Blank<0u>&&, auto const General::Parser::SCPI::SCPI<Electronics::System::System, Electronics::System::Comms>(Electronics::System::System&, Electronics::System::Comms&)::{lambda(auto:1)#9}&&)::{lambda(auto const General::Parser::SCPI::SCPI<Electronics::System::System, Electronics::System::Comms>(auto:1&, auto:2&)::{lambda(auto:1)#9})#1}>, General::Parser::SCPI::End<General::Parser::SCPI::CommandInternal<General::Parser::Chain<General::Parser::Keyword<5u, 3u> const&, General::Parser::Optional<General::Parser::Required<3u> > const&>, General::Parser::SCPI::None<0u>, General::Parser::SCPI::Blank<0u> >, auto General::Parser::SCPI::Command<General::Parser::Chain<General::Parser::Keyword<5u, 3u> const&, General::Parser::Optional<General::Parser::Required<3u> > const&>, General::Parser::SCPI::None<0u>, General::Parser::SCPI::Blank<0u>, auto const General::Parser::SCPI::SCPI<Electronics::System::System, Electronics::System::Comms>(Electronics::System::System&, Electronics::System::Comms&)::{lambda(auto:1)#10}>(auto const General::Parser::SCPI::SCPI<Electronics::System::System, Electronics::System::Comms>(Electronics::System::System&, Electronics::System::Comms&)::{lambda(auto:1)#9}, Electronics::System::System&&, General::Parser::SCPI::Blank<0u>, auto const General::Parser::SCPI::SCPI<Electronics::System::System, Electronics::System::Comms>(Electronics::System::System&, Electronics::System::Comms&)::{lambda(auto:1)#10})::{lambda(auto const General::Parser::SCPI::SCPI<Electronics::System::System, Electronics::System::Comms>(auto:1&, auto:2&)::{lambda(auto:1)#9})#1}>, General::Parser::SCPI::End<General::Parser::SCPI::CommandInternal<General::Parser::Chain<General::Parser::Keyword<4u, 2u> const&, General::Parser::Optional<General::Parser::Required<3u> > const&>, General::Parser::SCPI::None<0u>, General::Parser::SCPI::Blank<0u> >, auto General::Parser::SCPI::Command<General::Parser::SCPI::End<General::Parser::SCPI::CommandInternal<General::Parser::Chain<General::Parser::Keyword<5u, 3u> const&, General::Parser::Optional<General::Parser::Required<3u> > const&>, General::Parser::SCPI::None<0u>, General::Parser::SCPI::Blank<0u> >, auto General::Parser::SCPI::Command<General::Parser::Chain<General::Parser::Keyword<5u, 3u> const&, General::Parser::Optional<General::Parser::Required<3u> > const&>, General::Parser::SCPI::None<0u>, General::Parser::SCPI::Blank<0u>, auto const General::Parser::SCPI::SCPI<Electronics::System::System, Electronics::System::Comms>(Electronics::System::System&, Electronics::System::Comms&)::{lambda(auto:1)#10}>(auto const General::Parser::SCPI::SCPI<Electronics::System::System, Electronics::System::Comms>(Electronics::System::System&, Electronics::System::Comms&)::{lambda(auto:1)#9}, Electronics::System::System&&, General::Parser::SCPI::Blank<0u>, auto const General::Parser::SCPI::SCPI<Electronics::System::System, Electronics::System::Comms>(Electronics::System::System&, Electronics::System::Comms&)::{lambda(auto:1)#10})::{lambda(auto const General::Parser::SCPI::SCPI<Electronics::System::System, Electronics::System::Comms>(auto:1&, auto:2&)::{lambda(auto:1)#9})#1}>, General::Parser::SCPI::None<0u>, General::Parser::SCPI::Blank<0u>, auto const General::Parser::SCPI::SCPI<Electronics::System::System, Electronics::System::Comms>(Electronics::System::System&, Electronics::System::Comms&)::{lambda(auto:1)#11}>(auto const General::Parser::SCPI::SCPI<Electronics::System::System, Electronics::System::Comms>(Electronics::System::System&, Electronics::System::Comms&)::{lambda(auto:1)#9}, Electronics::System::System&&, General::Parser::SCPI::Blank<0u>, auto const General::Parser::SCPI::SCPI<Electronics::System::System, Electronics::System::Comms>(Electronics::System::System&, Electronics::System::Comms&)::{lambda(auto:1)#11})::{lambda(auto const General::Parser::SCPI::SCPI<Electronics::System::System, Elect The bug seems unrelated to the code itself. I concluded that because of the following: 1. I have no issue linking on x86 with MSVC or clang, but I cannot use these as they don’t fully support my platform. 2. If I enable code which triggers the error I can disable other unrelated code to make it work again. I believe it to be related in some way to heavy template usage, I use template classes which call common functions in a safe manner. The target has 128K of flash and I’m currently using around 50K. I’ve written a post on stack overflow : https://stackoverflow.com/questions/53257425/undocumented-linker-issue-ld-returned-253-exit-status How can I assist you in isolating this issue? This is for a commercial project, its open source ultimately but its for a physical product. This issue is holding up development, I would appreciate greatly any help.
Hi David, > How can I assist you in isolating this issue? To me this sounds like a resource issue. Ie I suspect that the linker is running out of memory, or maybe stack space, and crashing. Things that you can try: * Use a newer version of the linker. The latest release is 2.31.1. * Try running the linker with its memory overhead reduction options: --no-keep-memory and --reduce-memory-overhead You may also find it useful to add the --print-memory-usage option to see if this produces any useful output. * Try using the gold linker instead of the bfd based linker. * Try linking on a machine with more resources available. Or, if possible, a machine running a different OS. * Try running the linker from inside GDB, so that it might capture the problem. In order to obtain the command line for the linker you can add -Wl,-debug to the g++ command line. * See if you can create a reproducible testcase that we can examine ourselves. I suspect however that it might be too big to upload, but it would be worth a try. Cheers Nick
Created attachment 11428 [details] AB47CDC69A0948D5A9074F7BB7230378[7204541].png I’m not really sure how to use ld gold with arm-embedded toolchain, I don’t think it is included in the toolchain. Do you know a way I can use ld.gold or lld? I am currently working from within windows. I tried with those flags, with debug, but same error: collect2 version 7.2.1 20170904 (release) [ARM/embedded-7-branch revision 255204] ld_file_name = c:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe c_file_name = C:\Users\David\AppData\Roaming\xPacks\@gnu-mcu-eclipse\arm-none-eabi-gcc\7.2.1-1.1.5\.content\bin/arm-none-eabi-g++.exe nm_file_name = c:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/nm.exe strip_file_name = c:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/strip.exe c_file = C:\Users\David\AppData\Local\Temp\cc0uuTr5.c o_file = C:\Users\David\AppData\Local\Temp\ccQPOCJ0.o COLLECT_GCC_OPTIONS = '-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' '-L../ldscripts' '-specs=nano.specs' '-o' 'uSupply Firmware V1_0.elf' COLLECT_GCC = arm-none-eabi-g++ COMPILER_PATH = c:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../lib/gcc/arm-none-eabi/7.2.1/;c:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../lib/gcc/;c:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ LIBRARY_PATH = c:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../lib/gcc/arm-none-eabi/7.2.1/thumb/v6-m/;c:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib/thumb/v6-m/;c:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../arm-none-eabi/lib/thumb/v6-m/;c:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../lib/gcc/arm-none-eabi/7.2.1/;c:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../lib/gcc/;c:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib/;c:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../arm-none-eabi/lib/ c:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe --sysroot=c:\users\david\appdata\roaming\xpacks\@gnu-mcu-eclipse\arm-none-eabi-gcc\7.2.1-1.1.5\.content\bin\../arm-none-eabi -X -o uSupply Firmware V1_0.elf -L../ldscripts -Lc:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../lib/gcc/arm-none-eabi/7.2.1/thumb/v6-m -Lc:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib/thumb/v6-m -Lc:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../arm-none-eabi/lib/thumb/v6-m -Lc:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../lib/gcc/arm-none-eabi/7.2.1 -Lc:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../lib/gcc -Lc:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib -Lc:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2.1-1.1.5/.content/bin/../arm-none-eabi/lib --gc-sections --no-keep-memory --reduce-memory-overhead --print-memory-usage -Map uSupply Firmware V1_0.map ./system/src/stm32f0-stdperiph/stm32f0xx_adc.o ./system/src/stm32f0-stdperiph/stm32f0xx_can.o ./system/src/stm32f0-stdperiph/stm32f0xx_cec.o ./system/src/stm32f0-stdperiph/stm32f0xx_comp.o ./system/src/stm32f0-stdperiph/stm32f0xx_crc.o ./system/src/stm32f0-stdperiph/stm32f0xx_crs.o ./system/src/stm32f0-stdperiph/stm32f0xx_dac.o ./system/src/stm32f0-stdperiph/stm32f0xx_dbgmcu.o ./system/src/stm32f0-stdperiph/stm32f0xx_dma.o ./system/src/stm32f0-stdperiph/stm32f0xx_exti.o ./system/src/stm32f0-stdperiph/stm32f0xx_flash.o ./system/src/stm32f0-stdperiph/stm32f0xx_gpio.o ./system/src/stm32f0-stdperiph/stm32f0xx_i2c.o ./system/src/stm32f0-stdperiph/stm32f0xx_iwdg.o ./system/src/stm32f0-stdperiph/stm32f0xx_misc.o ./system/src/stm32f0-stdperiph/stm32f0xx_pwr.o ./system/src/stm32f0-stdperiph/stm32f0xx_rcc.o ./system/src/stm32f0-stdperiph/stm32f0xx_rtc.o ./system/src/stm32f0-stdperiph/stm32f0xx_spi.o ./system/src/stm32f0-stdperiph/stm32f0xx_syscfg.o ./system/src/stm32f0-stdperiph/stm32f0xx_tim.o ./system/src/stm32f0-stdperiph/stm32f0xx_usart.o ./system/src/stm32f0-stdperiph/stm32f0xx_wwdg.o ./system/src/newlib/_cxx.o ./system/src/newlib/_exit.o ./system/src/newlib/_sbrk.o ./system/src/newlib/_startup.o ./system/src/newlib/_syscalls.o ./system/src/newlib/assert.o ./system/src/diag/Trace.o ./system/src/diag/trace_impl.o ./system/src/cortexm/_initialize_hardware.o ./system/src/cortexm/_reset_hardware.o ./system/src/cortexm/exception_handlers.o ./system/src/cmsis/system_stm32f0xx.o ./system/src/cmsis/vectors_stm32f0xx.o ./src/peripherals/Interrupt.o ./src/_write.o ./src/main.o -lstdc++_nano -lm --start-group -lgcc -lg_nano -lc_nano --end-group --start-group -lgcc -lc_nano --end-group -T ../ldscripts/mem.ld -T ../ldscripts/sections.ld -T ../ldscripts/libs.ld collect2.exe: error: ld returned 253 exit status [Leaving C:\Users\David\AppData\Local\Temp\cc0uuTr5.c] [Leaving C:\Users\David\AppData\Local\Temp\ccQPOCJ0.o] make: *** [makefile:65: uSupply Firmware V1_0.elf] Error 1 [cid:image001.png@01D448F4.339F3940] David Ledger - Electronics Design Engineer www.eevblog.com<http://www.eevblog.com> Skype: david.j.ledger ________________________________ From: nickc at redhat dot com <sourceware-bugzilla@sourceware.org> Sent: Thursday, November 22, 2018 11:22:14 PM To: davidledger@live.com.au 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%7C8780db8dbe3a4ae4e97e08d650752582%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636784861399878197&sdata=60emLqpCzW3C5AggVAZODUl2PIgXJ0fm34h3zQZzsWc%3D&reserved=0 Nick Clifton <nickc at redhat dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nickc at redhat dot com --- Comment #1 from Nick Clifton <nickc at redhat dot com> --- Hi David, > How can I assist you in isolating this issue? To me this sounds like a resource issue. Ie I suspect that the linker is running out of memory, or maybe stack space, and crashing. Things that you can try: * Use a newer version of the linker. The latest release is 2.31.1. * Try running the linker with its memory overhead reduction options: --no-keep-memory and --reduce-memory-overhead You may also find it useful to add the --print-memory-usage option to see if this produces any useful output. * Try using the gold linker instead of the bfd based linker. * Try linking on a machine with more resources available. Or, if possible, a machine running a different OS. * Try running the linker from inside GDB, so that it might capture the problem. In order to obtain the command line for the linker you can add -Wl,-debug to the g++ command line. * See if you can create a reproducible testcase that we can examine ourselves. I suspect however that it might be too big to upload, but it would be worth a try. Cheers Nick -- You are receiving this mail because: You reported the bug.
(In reply to David Ledger from comment #2) Hi David, > I’m not really sure how to use ld gold with arm-embedded toolchain, I don’t > think it is included in the toolchain. > Do you know a way I can use ld.gold or lld? Don't bother. If they are not easily available then they will not help. (I was hoping to be able to say "use gold as a workaround", but this only works if you do not have to jump through hoops in order to use it. > I tried with those flags, with debug, but same error: OK, it was worth a shot. :-( > c:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2. > 1-1.1.5/.content/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none- > eabi/bin/ld.exe > --sysroot=c:\users\david\appdata\roaming\xpacks\@gnu-mcu-eclipse\arm-none- > eabi-gcc\7.2.1-1.1.5\.content\bin\../arm-none-eabi -X -o uSupply Firmware > V1_0.elf -L../ldscripts > -Lc:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7. > 2.1-1.1.5/.content/bin/../lib/gcc/arm-none-eabi/7.2.1/thumb/v6-m > -Lc:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7. > 2.1-1.1.5/.content/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none- > eabi/lib/thumb/v6-m > -Lc:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7. > 2.1-1.1.5/.content/bin/../arm-none-eabi/lib/thumb/v6-m > -Lc:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7. > 2.1-1.1.5/.content/bin/../lib/gcc/arm-none-eabi/7.2.1 > -Lc:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7. > 2.1-1.1.5/.content/bin/../lib/gcc > -Lc:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7. > 2.1-1.1.5/.content/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none- > eabi/lib > -Lc:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7. > 2.1-1.1.5/.content/bin/../arm-none-eabi/lib --gc-sections --no-keep-memory > --reduce-memory-overhead --print-memory-usage -Map uSupply Firmware V1_0.map > ./system/src/stm32f0-stdperiph/stm32f0xx_adc.o > ./system/src/stm32f0-stdperiph/stm32f0xx_can.o > ./system/src/stm32f0-stdperiph/stm32f0xx_cec.o > ./system/src/stm32f0-stdperiph/stm32f0xx_comp.o > ./system/src/stm32f0-stdperiph/stm32f0xx_crc.o > ./system/src/stm32f0-stdperiph/stm32f0xx_crs.o > ./system/src/stm32f0-stdperiph/stm32f0xx_dac.o > ./system/src/stm32f0-stdperiph/stm32f0xx_dbgmcu.o > ./system/src/stm32f0-stdperiph/stm32f0xx_dma.o > ./system/src/stm32f0-stdperiph/stm32f0xx_exti.o > ./system/src/stm32f0-stdperiph/stm32f0xx_flash.o > ./system/src/stm32f0-stdperiph/stm32f0xx_gpio.o > ./system/src/stm32f0-stdperiph/stm32f0xx_i2c.o > ./system/src/stm32f0-stdperiph/stm32f0xx_iwdg.o > ./system/src/stm32f0-stdperiph/stm32f0xx_misc.o > ./system/src/stm32f0-stdperiph/stm32f0xx_pwr.o > ./system/src/stm32f0-stdperiph/stm32f0xx_rcc.o > ./system/src/stm32f0-stdperiph/stm32f0xx_rtc.o > ./system/src/stm32f0-stdperiph/stm32f0xx_spi.o > ./system/src/stm32f0-stdperiph/stm32f0xx_syscfg.o > ./system/src/stm32f0-stdperiph/stm32f0xx_tim.o > ./system/src/stm32f0-stdperiph/stm32f0xx_usart.o > ./system/src/stm32f0-stdperiph/stm32f0xx_wwdg.o ./system/src/newlib/_cxx.o > ./system/src/newlib/_exit.o ./system/src/newlib/_sbrk.o > ./system/src/newlib/_startup.o ./system/src/newlib/_syscalls.o > ./system/src/newlib/assert.o ./system/src/diag/Trace.o > ./system/src/diag/trace_impl.o ./system/src/cortexm/_initialize_hardware.o > ./system/src/cortexm/_reset_hardware.o > ./system/src/cortexm/exception_handlers.o > ./system/src/cmsis/system_stm32f0xx.o ./system/src/cmsis/vectors_stm32f0xx.o > ./src/peripherals/Interrupt.o ./src/_write.o ./src/main.o -lstdc++_nano -lm > --start-group -lgcc -lg_nano -lc_nano --end-group --start-group -lgcc > -lc_nano --end-group -T ../ldscripts/mem.ld -T ../ldscripts/sections.ld -T > ../ldscripts/libs.ld Are you able to invoke the command line above ? IE, can you bypass collect2.exe altogether and run the linker directly ? If that works, (in the sense that the linker fails and returns an error exit status), then you could run the same command from inside gdb, and investigate where the error result is being generated... > To me this sounds like a resource issue. Ie I suspect that the linker is > running out of memory, or maybe stack space, and crashing. I think that this is still the most likely cause for the problem. How much memory does your machine have ? Can you run the same build on a machine with more memory and see if that makes a difference ? > * Use a newer version of the linker. The latest release is 2.31.1. I also still recommend giving this option a try. Cheers Nick
Unhandled exception at 0x0000000000402B06 in arm-none-eabi-ld.bfd.exe: 0xC00000FD: Stack overflow (parameters: 0x0000000000000001, 0x0000000000543830). Ran it in MSVC debugger because I don't know how to use GDB but it appears a stack overflow occured...
Created attachment 11436 [details] attachment-49407-0.html I just realised I can send you this (sorry about double message) https://1drv.ms/u/s!AvPNFIn52ti4setF5UJ8_nCYvZgfkg That is less than 1 Mb and it causes the issue with the ld linker packaged with this : “GNU Tools for ARM Embedded Processors 7-2018q2-update Release<https://launchpad.net/gcc-arm-embedded/+announcement/15015>” From: nickc at redhat dot com<mailto:sourceware-bugzilla@sourceware.org> Sent: Tuesday, 4 December 2018 10:05 PM To: davidledger@live.com.au<mailto:davidledger@live.com.au> 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%7C77635c23acd245eb07bd08d659d85a14%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636795183093229235&sdata=YypTnyPSpOEStXOBOjVokVER5AOHc4jGnXioJUWm1ek%3D&reserved=0 --- Comment #3 from Nick Clifton <nickc at redhat dot com> --- (In reply to David Ledger from comment #2) Hi David, > I’m not really sure how to use ld gold with arm-embedded toolchain, I don’t > think it is included in the toolchain. > Do you know a way I can use ld.gold or lld? Don't bother. If they are not easily available then they will not help. (I was hoping to be able to say "use gold as a workaround", but this only works if you do not have to jump through hoops in order to use it. > I tried with those flags, with debug, but same error: OK, it was worth a shot. :-( > c:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7.2. > 1-1.1.5/.content/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none- > eabi/bin/ld.exe > --sysroot=c:\users\david\appdata\roaming\xpacks\@gnu-mcu-eclipse\arm-none- > eabi-gcc\7.2.1-1.1.5\.content\bin\../arm-none-eabi -X -o uSupply Firmware > V1_0.elf -L../ldscripts > -Lc:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7. > 2.1-1.1.5/.content/bin/../lib/gcc/arm-none-eabi/7.2.1/thumb/v6-m > -Lc:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7. > 2.1-1.1.5/.content/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none- > eabi/lib/thumb/v6-m > -Lc:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7. > 2.1-1.1.5/.content/bin/../arm-none-eabi/lib/thumb/v6-m > -Lc:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7. > 2.1-1.1.5/.content/bin/../lib/gcc/arm-none-eabi/7.2.1 > -Lc:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7. > 2.1-1.1.5/.content/bin/../lib/gcc > -Lc:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7. > 2.1-1.1.5/.content/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none- > eabi/lib > -Lc:/users/david/appdata/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/7. > 2.1-1.1.5/.content/bin/../arm-none-eabi/lib --gc-sections --no-keep-memory > --reduce-memory-overhead --print-memory-usage -Map uSupply Firmware V1_0.map > ./system/src/stm32f0-stdperiph/stm32f0xx_adc.o > ./system/src/stm32f0-stdperiph/stm32f0xx_can.o > ./system/src/stm32f0-stdperiph/stm32f0xx_cec.o > ./system/src/stm32f0-stdperiph/stm32f0xx_comp.o > ./system/src/stm32f0-stdperiph/stm32f0xx_crc.o > ./system/src/stm32f0-stdperiph/stm32f0xx_crs.o > ./system/src/stm32f0-stdperiph/stm32f0xx_dac.o > ./system/src/stm32f0-stdperiph/stm32f0xx_dbgmcu.o > ./system/src/stm32f0-stdperiph/stm32f0xx_dma.o > ./system/src/stm32f0-stdperiph/stm32f0xx_exti.o > ./system/src/stm32f0-stdperiph/stm32f0xx_flash.o > ./system/src/stm32f0-stdperiph/stm32f0xx_gpio.o > ./system/src/stm32f0-stdperiph/stm32f0xx_i2c.o > ./system/src/stm32f0-stdperiph/stm32f0xx_iwdg.o > ./system/src/stm32f0-stdperiph/stm32f0xx_misc.o > ./system/src/stm32f0-stdperiph/stm32f0xx_pwr.o > ./system/src/stm32f0-stdperiph/stm32f0xx_rcc.o > ./system/src/stm32f0-stdperiph/stm32f0xx_rtc.o > ./system/src/stm32f0-stdperiph/stm32f0xx_spi.o > ./system/src/stm32f0-stdperiph/stm32f0xx_syscfg.o > ./system/src/stm32f0-stdperiph/stm32f0xx_tim.o > ./system/src/stm32f0-stdperiph/stm32f0xx_usart.o > ./system/src/stm32f0-stdperiph/stm32f0xx_wwdg.o ./system/src/newlib/_cxx.o > ./system/src/newlib/_exit.o ./system/src/newlib/_sbrk.o > ./system/src/newlib/_startup.o ./system/src/newlib/_syscalls.o > ./system/src/newlib/assert.o ./system/src/diag/Trace.o > ./system/src/diag/trace_impl.o ./system/src/cortexm/_initialize_hardware.o > ./system/src/cortexm/_reset_hardware.o > ./system/src/cortexm/exception_handlers.o > ./system/src/cmsis/system_stm32f0xx.o ./system/src/cmsis/vectors_stm32f0xx.o > ./src/peripherals/Interrupt.o ./src/_write.o ./src/main.o -lstdc++_nano -lm > --start-group -lgcc -lg_nano -lc_nano --end-group --start-group -lgcc > -lc_nano --end-group -T ../ldscripts/mem.ld -T ../ldscripts/sections.ld -T > ../ldscripts/libs.ld Are you able to invoke the command line above ? IE, can you bypass collect2.exe altogether and run the linker directly ? If that works, (in the sense that the linker fails and returns an error exit status), then you could run the same command from inside gdb, and investigate where the error result is being generated... > To me this sounds like a resource issue. Ie I suspect that the linker is > running out of memory, or maybe stack space, and crashing. I think that this is still the most likely cause for the problem. How much memory does your machine have ? Can you run the same build on a machine with more memory and see if that makes a difference ? > * Use a newer version of the linker. The latest release is 2.31.1. I also still recommend giving this option a try. Cheers Nick -- You are receiving this mail because: You reported the bug.
(In reply to David Ledger from comment #5) Hi David, Do I run 'Build Command.bat' in order to reproduce the problem ? If so then please could you upload the missing linker scripts (mem.ld, sections.ld and libs.ld) and the missing libraries (libc, libm, libgcc, libstdc++-v3). Cheers Nick PS. If you do not use your own linker scripts, but instead use the script built in to the linker, does the error still happen ?
(In reply to David Ledger from comment #4) Hi David, > Unhandled exception at 0x0000000000402B06 in arm-none-eabi-ld.bfd.exe: > 0xC00000FD: Stack overflow (parameters: 0x0000000000000001, > 0x0000000000543830). > > Ran it in MSVC debugger because I don't know how to use GDB but it appears a > stack overflow occured... Sorry - I missed this comment. So this would probably explain what is going wrong. Of course it then begs the question of why the stack exhaustion is occurring. Do you have a limited amount of stack space available to applications on your build machine ? In the MSVC debugger, are you able to determine what the stack backtrace looks like when it runs out of space ? (I am wondering if there is a bug leading to infinite recursion). Or maybe there is a function in the linker which allocates memory on the stack, and it is asking for a huge amount of memory... Cheers Nick
Created attachment 11445 [details] AB47CDC69A0948D5A9074F7BB7230378[7346783].png Sorry, https://1drv.ms/f/s!AvPNFIn52ti4sZZTLbAALA-e07ySeg Doesn’t look very deep (the stack frame) [cid:image002.png@01D4908E.C7A6F330] 3 frames down is a stack frame at address 00000000000001, this seems like a suspect address for a function. The stack frame doesn’t appear to repeat any function calls (no repeated addresses, so I don’t think infinite recursion). I also tried to increase the stack size of the executable to 64MB using editbin /STACK:64000000 ld.exe (which is insanely large). This didn’t change the issue. [cid:image001.png@01D448F4.339F3940] David Ledger - Electronics Design Engineer www.eevblog.com<http://www.eevblog.com> Skype: david.j.ledger ________________________________ From: nickc at redhat dot com <sourceware-bugzilla@sourceware.org> Sent: Friday, December 7, 2018 9:49:00 PM To: davidledger@live.com.au 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%7Cf83c400e369044d6f2e808d65c5fb4bd%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636797963455131558&sdata=gVlh8VjmNiakVbD9nAy7fTnMy0jK00uZPeFfK3w0pM0%3D&reserved=0 --- Comment #7 from Nick Clifton <nickc at redhat dot com> --- (In reply to David Ledger from comment #4) Hi David, > Unhandled exception at 0x0000000000402B06 in arm-none-eabi-ld.bfd.exe: > 0xC00000FD: Stack overflow (parameters: 0x0000000000000001, > 0x0000000000543830). > > Ran it in MSVC debugger because I don't know how to use GDB but it appears a > stack overflow occured... Sorry - I missed this comment. So this would probably explain what is going wrong. Of course it then begs the question of why the stack exhaustion is occurring. Do you have a limited amount of stack space available to applications on your build machine ? In the MSVC debugger, are you able to determine what the stack backtrace looks like when it runs out of space ? (I am wondering if there is a bug leading to infinite recursion). Or maybe there is a function in the linker which allocates memory on the stack, and it is asking for a huge amount of memory... Cheers Nick -- You are receiving this mail because: You reported the bug.
Created attachment 11446 [details] 5EDA8A9B32B446CFBC8CCCCD0CC58134.png
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://docs.microsoft.com/en-us/sysinternals/downloads/procdump 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.
Created attachment 11452 [details] AB47CDC69A0948D5A9074F7BB7230378[7402997].png 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-bugzilla@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.
Hi David, Interesting, if you can reproduce the issue on Linux than that makes it easier. My gitlab username is @Mistuke
Created attachment 11453 [details] AB47CDC69A0948D5A9074F7BB7230378[7571657].png You should now be able to clone the project: https://gitlab.com/Sepps/usupply-firmware git@gitlab.com:Sepps/usupply-firmware.git<mailto:git@gitlab.com:Sepps/usupply-firmware.git> https://gitlab.com/Sepps/usupply-firmware.git [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 <sourceware-bugzilla@sourceware.org> Sent: Wednesday, December 12, 2018 6:38:28 PM To: davidledger@live.com.au 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%7Cfc993a75c8bd4d7dfc8b08d66004d0ab%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636801971127028832&sdata=O4hGTLPAujt7jpYyKj2UY4rOExffLfBXOZ5b%2BD0PHBQ%3D&reserved=0 --- Comment #12 from Tamar Christina <tnfchris at sourceware dot org> --- Hi David, Interesting, if you can reproduce the issue on Linux than that makes it easier. My gitlab username is @Mistuke -- You are receiving this mail because: You reported the bug.
Gitlab is refusing the clone, "GitLab: You are not allowed to download code from this project." Also can't see the code via the weburl, seems the permissions are not correct yet.
Created attachment 11454 [details] AB47CDC69A0948D5A9074F7BB7230378[7576680].png Darn it, you should now be a reporter on the git. Also I made an issue that has some information which might shorten the search to isolate the problem: https://gitlab.com/Sepps/usupply-firmware/issues/1 [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 <sourceware-bugzilla@sourceware.org> Sent: Wednesday, December 12, 2018 7:18:52 PM To: davidledger@live.com.au 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%7Cdbd0e0d48f48489487e608d6600a7615%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636801995381050253&sdata=TjmwItHJ9Yy2PNsc7R481wueih9y9J7EC12UzRWhlQ8%3D&reserved=0 --- Comment #14 from Tamar Christina <tnfchris at sourceware dot org> --- Gitlab is refusing the clone, "GitLab: You are not allowed to download code from this project." Also can't see the code via the weburl, seems the permissions are not correct yet. -- You are receiving this mail because: You reported the bug.
Created attachment 11455 [details] AB47CDC69A0948D5A9074F7BB7230378[7578306].png Are you able to access it now? [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 <sourceware-bugzilla@sourceware.org> Sent: Wednesday, December 12, 2018 7:18:52 PM To: davidledger@live.com.au 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%7Cdbd0e0d48f48489487e608d6600a7615%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636801995381050253&sdata=TjmwItHJ9Yy2PNsc7R481wueih9y9J7EC12UzRWhlQ8%3D&reserved=0 --- Comment #14 from Tamar Christina <tnfchris at sourceware dot org> --- Gitlab is refusing the clone, "GitLab: You are not allowed to download code from this project." Also can't see the code via the weburl, seems the permissions are not correct yet. -- You are receiving this mail because: You reported the bug.
> Are you able to access it now? Yup, I'll try to repro now. Thanks!
Hi David, I still can't seem to reproduce it, neither on linux. I tried all 7 pass modes and they all build fine. [100%] Linking CXX executable STM32F072.elf [100%] Built target STM32F072.elf text data bss dec hex filename 21700 400 5916 28016 6d70 STM32F072.elf [100%] Built target size Can you generate a coredump on linux? you can set it to automatically generate one on a crash by changing the core file limit. ulimit -c unlimited should do it and rerunning the build, should generate a core file for ld. you can see your current limit with ulimit -a so you know what to change it back to (likely 0). Thanks, Tamar
Created attachment 11456 [details] attachment-40090-0.html Disable all the modes, those are pass modes. It only fails when its in fail mode (none of the pass modes are enabled). Anyway, sorry for not being clear there. David Ledger - Electronics Design Engineer Skype: david.j.ledger ________________________________ From: tnfchris at sourceware dot org <sourceware-bugzilla@sourceware.org> Sent: Wednesday, December 12, 2018 3:25:21 PM To: davidledger@live.com.au 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%7Cb15d731f0e1a41b06fa408d66017f02c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636802053264019698&sdata=xH18cr0rgCGdIBFVbguPC2WCtN3j1bEJ0GR3KJRRJNg%3D&reserved=0 --- Comment #18 from Tamar Christina <tnfchris at sourceware dot org> --- Hi David, I still can't seem to reproduce it, neither on linux. I tried all 7 pass modes and they all build fine. [100%] Linking CXX executable STM32F072.elf [100%] Built target STM32F072.elf text data bss dec hex filename 21700 400 5916 28016 6d70 STM32F072.elf [100%] Built target size Can you generate a coredump on linux? you can set it to automatically generate one on a crash by changing the core file limit. ulimit -c unlimited should do it and rerunning the build, should generate a core file for ld. you can see your current limit with ulimit -a so you know what to change it back to (likely 0). Thanks, Tamar -- You are receiving this mail because: You reported the bug.
Thanks, Confirmed, able to reproduce it now. Will take a look.
It seems that Nick was right that this hitting the stack limit. The reason it's doing so is that you have a quite a lot of templates in your C++ code. The linker seems to segfault when it's trying to demangle this symbol _ZNSt11_Tuple_implILj0EJN7General6Parser4NodeINS1_7KeywordILj4ELj2EEENS1_6StatesIJNS2_INS3_ILj5ELj3EEENS5_IJNS1_4SCPI3EndINS7_15CommandInternalIRKS4_JNS1_5ParamIfEENS7_5BlankILj0EEEEEEZNS7_7CommandISB which is done in libiberty https://github.com/gcc-mirror/gcc/blob/master/libiberty/cp-demangle.c#L4315 This hits two VLAs expanding two structs of 16 bytes. However you have 1485065 entries in dpi.num_copy_templates causing it to push the stack down (dpi.num_saved_scopes + dpi.num_copy_templates) * 16 bytes. Which is 190129824 bytes, or 181mb and so way over blowing your stack limit. I tried with GCC 9 which seems to do a better job with the templates and it works there. But I guess the real fix is to not use those VLAs in libiberty. But I believe that's maintained by GCC if I'm not mistaken. for now, you can work around it by increasing your ulimit.
Created attachment 11458 [details] attachment-73364-0.html Thankyou! Whoops. Was trying to get the data structure built at compile time. Anyway to get it to work within windows, I tried EditBin.exe but it didn’t work. I set the reserve stack to 512Mb. How did you get ld. from GCC9 to work for this target? David Ledger - Electronics Design Engineer Skype: david.j.ledger From: tnfchris at sourceware dot org<mailto:sourceware-bugzilla@sourceware.org> Sent: Thursday, 13 December 2018 3:29 AM To: davidledger@live.com.au<mailto:davidledger@live.com.au> 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%7Cc2f08691526d4db6673908d6604ef4bc%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636802289560134947&sdata=D7tZTAXmrosCpuTh9UOS%2BepgSt1G4ohLY0FVy5eZ6Gk%3D&reserved=0 --- Comment #21 from Tamar Christina <tnfchris at sourceware dot org> --- It seems that Nick was right that this hitting the stack limit. The reason it's doing so is that you have a quite a lot of templates in your C++ code. The linker seems to segfault when it's trying to demangle this symbol _ZNSt11_Tuple_implILj0EJN7General6Parser4NodeINS1_7KeywordILj4ELj2EEENS1_6StatesIJNS2_INS3_ILj5ELj3EEENS5_IJNS1_4SCPI3EndINS7_15CommandInternalIRKS4_JNS1_5ParamIfEENS7_5BlankILj0EEEEEEZNS7_7CommandISB which is done in libiberty https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgcc-mirror%2Fgcc%2Fblob%2Fmaster%2Flibiberty%2Fcp-demangle.c%23L4315&data=02%7C01%7C%7Cc2f08691526d4db6673908d6604ef4bc%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636802289560134947&sdata=%2BAiATfI%2BMDFzFiSh6FzxQhqepnlGtq280Qk3dAryqbY%3D&reserved=0 This hits two VLAs expanding two structs of 16 bytes. However you have 1485065 entries in dpi.num_copy_templates causing it to push the stack down (dpi.num_saved_scopes + dpi.num_copy_templates) * 16 bytes. Which is 190129824 bytes, or 181mb and so way over blowing your stack limit. I tried with GCC 9 which seems to do a better job with the templates and it works there. But I guess the real fix is to not use those VLAs in libiberty. But I believe that's maintained by GCC if I'm not mistaken. for now, you can work around it by increasing your ulimit. -- You are receiving this mail because: You reported the bug.
> Anyway to get it to work within windows, I tried EditBin.exe but it didn’t work. I set the reserve stack to 512Mb. I suspect the reason that isn't working is that setting the reserve stack just reserves the virtual memory but doesn't change the committed memory, and so the OS only has allocated still the original amount. On windows when the stack is allocated you're not allowed to do it more than a pagesize at a time. Normally applications emit a __chkstk_ms call for this but I can't find any such calls in the ld binary. Ofcourse it is likely the case that I can't find it because the binaries have been fully stripped.. You could try using editbin but also specifying the commit size. This will only work if you actually have enough physical memory to back the requested size. But I believe it should work then too. > How did you get ld. from GCC9 to work for this target? The LD was actually the same, it's the compiler that generated less symbols. But it's not a clean migration as GCC9 no longer allows SP to be clobbered via inline assembly. So I had to comment out some parts of the code. A bug needs to be raised against libiberty in GCC for a proper fix.
Created attachment 11459 [details] attachment-88034-0.html Should I raise the bug with them or does your team do that? David Ledger - Electronics Design Engineer Skype: david.j.ledger ________________________________ From: tnfchris at sourceware dot org <sourceware-bugzilla@sourceware.org> Sent: Thursday, December 13, 2018 9:17:10 PM To: davidledger@live.com.au 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%7Cc4d42d5362ab4c12938108d660e42791%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636802930366926937&sdata=xPnBO8%2F%2F44Pa0dnjLrE2mr4XwFPeHw44Va8wIe1mwrE%3D&reserved=0 --- Comment #23 from Tamar Christina <tnfchris at sourceware dot org> --- > Anyway to get it to work within windows, I tried EditBin.exe but it didn’t work. I set the reserve stack to 512Mb. I suspect the reason that isn't working is that setting the reserve stack just reserves the virtual memory but doesn't change the committed memory, and so the OS only has allocated still the original amount. On windows when the stack is allocated you're not allowed to do it more than a pagesize at a time. Normally applications emit a __chkstk_ms call for this but I can't find any such calls in the ld binary. Ofcourse it is likely the case that I can't find it because the binaries have been fully stripped.. You could try using editbin but also specifying the commit size. This will only work if you actually have enough physical memory to back the requested size. But I believe it should work then too. > How did you get ld. from GCC9 to work for this target? The LD was actually the same, it's the compiler that generated less symbols. But it's not a clean migration as GCC9 no longer allows SP to be clobbered via inline assembly. So I had to comment out some parts of the code. A bug needs to be raised against libiberty in GCC for a proper fix. -- You are receiving this mail because: You reported the bug.
I've reported it upstream at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88480 and will close this one since there's not much we can do in the linker to mitigate this unfortunately.
Moved to GCC bugzilla, once libiberty is fixed binutils needs to be synced.
Created attachment 11460 [details] AB47CDC69A0948D5A9074F7BB7230378[7594549].png I’ve tried ulimit -s unlimited and it still doesn’t work. Did you do anything other than that that might have caused it to work? [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 <sourceware-bugzilla@sourceware.org> Sent: Thursday, December 13, 2018 9:53:31 PM To: davidledger@live.com.au 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%7C0db61d09e5254258ab5608d660e93ae9%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636802952159249682&sdata=5fIzSF6RK6UkpqRH1wFqe2ADTYBq61jmEvKDVirVBoI%3D&reserved=0 Tamar Christina <tnfchris at sourceware dot org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED URL| |https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fbugzill&data=02%7C01%7C%7C0db61d09e5254258ab5608d660e93ae9%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636802952159249682&sdata=1k3%2B1a8os0JApLyE9fvJoeMDMxekvTaeD1p3LsSq1uE%3D&reserved=0 | |a/show_bug.cgi?id=88480 Resolution|--- |MOVED --- Comment #26 from Tamar Christina <tnfchris at sourceware dot org> --- Moved to GCC bugzilla, once libiberty is fixed binutils needs to be synced. -- You are receiving this mail because: You reported the bug.
No, it's the only thing I changed. ---- /d/t/t/p/usupply-firmware> ulimit -a | grep "\-s" Maximum stack size (kB, -s) 8192 /d/t/t/p/usupply-firmware> make clean; and make -j48 [ 2%] Building .... [100%] Linking CXX executable STM32F072.elf collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped compilation terminated. make[2]: *** [STM32F072.elf] Error 1 make[2]: *** Deleting file 'STM32F072.elf' CMakeFiles/STM32F072.elf.dir/build.make:653: recipe for target 'STM32F072.elf' failed make[1]: *** [CMakeFiles/STM32F072.elf.dir/all] Error 2 CMakeFiles/Makefile2:104: recipe for target 'CMakeFiles/STM32F072.elf.dir/all' failed make: *** [all] Error 2 Makefile:83: recipe for target 'all' failed /d/t/t/p/usupply-firmware> ulimit -s unlimited /d/t/t/p/usupply-firmware> ulimit -a | grep "\-s" Fri 10:47 Maximum stack size (kB, -s) unlimited /d/t/t/p/usupply-firmware> make [ 2%] Linking CXX executable STM32F072.elf [100%] Built target STM32F072.elf text data bss dec hex filename 38248 400 6440 45088 b020 STM32F072.elf [100%] Built target size ---- It would fail if you don't have enough free memory to back it though.
Created attachment 11466 [details] AB47CDC69A0948D5A9074F7BB7230378[7662854].png I just realised there was a flag: “CP_DYNAMIC_ARRAYS” In the cp-demangle.c source file in question. When this flag isn’t present the demangler allocates with alloc. I don’t really know how to integrate this into my compiler... Can I pass that as a compiler flag or something... Or do I need to recompile GCC entirely after deleting the flag? [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 <sourceware-bugzilla@sourceware.org> Sent: Friday, December 14, 2018 10:01:32 PM To: davidledger@live.com.au 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%7C9ad3aa2986c3400b1f8308d661b38527%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636803820988634130&sdata=YbDk3oOCYPAF9ACnvBU0yXaz5AuOf%2FvmxOSuxXJxUt4%3D&reserved=0 --- Comment #28 from Tamar Christina <tnfchris at sourceware dot org> --- No, it's the only thing I changed. ---- /d/t/t/p/usupply-firmware> ulimit -a | grep "\-s" Maximum stack size (kB, -s) 8192 /d/t/t/p/usupply-firmware> make clean; and make -j48 [ 2%] Building .... [100%] Linking CXX executable STM32F072.elf collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped compilation terminated. make[2]: *** [STM32F072.elf] Error 1 make[2]: *** Deleting file 'STM32F072.elf' CMakeFiles/STM32F072.elf.dir/build.make:653: recipe for target 'STM32F072.elf' failed make[1]: *** [CMakeFiles/STM32F072.elf.dir/all] Error 2 CMakeFiles/Makefile2:104: recipe for target 'CMakeFiles/STM32F072.elf.dir/all' failed make: *** [all] Error 2 Makefile:83: recipe for target 'all' failed /d/t/t/p/usupply-firmware> ulimit -s unlimited /d/t/t/p/usupply-firmware> ulimit -a | grep "\-s" Fri 10:47 Maximum stack size (kB, -s) unlimited /d/t/t/p/usupply-firmware> make [ 2%] Linking CXX executable STM32F072.elf [100%] Built target STM32F072.elf text data bss dec hex filename 38248 400 6440 45088 b020 STM32F072.elf [100%] Built target size ---- It would fail if you don't have enough free memory to back it though. -- You are receiving this mail because: You reported the bug.
Hmmm #ifdef __GNUC__ #define CP_DYNAMIC_ARRAYS #else So this should already be on by default.. Something fishy is going on there.. I'll try using a local build. I'll re-open the ticket in the meantime.
No, the code in the else branch uses alloca, which is still a stack allocation. Both branches uses the stack, so a third alternative is needed to do heap allocations.