Bug 23906 - LD Bug : Undocumented exit status 253
Summary: LD Bug : Undocumented exit status 253
Status: RESOLVED MOVED
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.29
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL: https://gcc.gnu.org/bugzilla/show_bug...
Keywords:
Depends on:
Blocks:
 
Reported: 2018-11-22 01:08 UTC by David Ledger
Modified: 2018-12-17 17:35 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed: 2018-12-12 00:00:00


Attachments
AB47CDC69A0948D5A9074F7BB7230378[7204541].png (4.27 KB, image/png)
2018-12-04 05:32 UTC, David Ledger
Details
attachment-49407-0.html (2.83 KB, text/html)
2018-12-07 07:36 UTC, David Ledger
Details
AB47CDC69A0948D5A9074F7BB7230378[7346783].png (4.27 KB, image/png)
2018-12-10 02:50 UTC, David Ledger
Details
5EDA8A9B32B446CFBC8CCCCD0CC58134.png (23.89 KB, image/png)
2018-12-10 02:50 UTC, David Ledger
Details
AB47CDC69A0948D5A9074F7BB7230378[7402997].png (4.27 KB, image/png)
2018-12-12 05:34 UTC, David Ledger
Details
AB47CDC69A0948D5A9074F7BB7230378[7571657].png (4.27 KB, image/png)
2018-12-12 08:08 UTC, David Ledger
Details
AB47CDC69A0948D5A9074F7BB7230378[7576680].png (4.27 KB, image/png)
2018-12-12 08:21 UTC, David Ledger
Details
AB47CDC69A0948D5A9074F7BB7230378[7578306].png (4.27 KB, image/png)
2018-12-12 08:23 UTC, David Ledger
Details
attachment-40090-0.html (1.73 KB, text/html)
2018-12-12 11:48 UTC, David Ledger
Details
attachment-73364-0.html (2.18 KB, text/html)
2018-12-13 01:59 UTC, David Ledger
Details
attachment-88034-0.html (1.95 KB, text/html)
2018-12-13 10:27 UTC, David Ledger
Details
AB47CDC69A0948D5A9074F7BB7230378[7594549].png (4.27 KB, image/png)
2018-12-14 00:38 UTC, David Ledger
Details
AB47CDC69A0948D5A9074F7BB7230378[7662854].png (4.27 KB, image/png)
2018-12-17 04:54 UTC, David Ledger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Ledger 2018-11-22 01:08:09 UTC
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.
Comment 1 Nick Clifton 2018-11-22 12:22:14 UTC
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
Comment 2 David Ledger 2018-12-04 05:32:33 UTC
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&amp;data=02%7C01%7C%7C8780db8dbe3a4ae4e97e08d650752582%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636784861399878197&amp;sdata=60emLqpCzW3C5AggVAZODUl2PIgXJ0fm34h3zQZzsWc%3D&amp;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.
Comment 3 Nick Clifton 2018-12-04 11:05:03 UTC
(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
Comment 4 David Ledger 2018-12-07 05:44:09 UTC
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...
Comment 5 David Ledger 2018-12-07 07:36:46 UTC
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&amp;data=02%7C01%7C%7C77635c23acd245eb07bd08d659d85a14%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636795183093229235&amp;sdata=YypTnyPSpOEStXOBOjVokVER5AOHc4jGnXioJUWm1ek%3D&amp;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.
Comment 6 Nick Clifton 2018-12-07 15:37:59 UTC
(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 ?
Comment 7 Nick Clifton 2018-12-07 16:19:00 UTC
(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
Comment 8 David Ledger 2018-12-10 02:49:59 UTC
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&amp;data=02%7C01%7C%7Cf83c400e369044d6f2e808d65c5fb4bd%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636797963455131558&amp;sdata=gVlh8VjmNiakVbD9nAy7fTnMy0jK00uZPeFfK3w0pM0%3D&amp;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.
Comment 9 David Ledger 2018-12-10 02:50:00 UTC
Created attachment 11446 [details]
5EDA8A9B32B446CFBC8CCCCD0CC58134.png
Comment 10 Tamar Christina 2018-12-10 13:18:24 UTC
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.
Comment 11 David Ledger 2018-12-12 05:34:21 UTC
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&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.
Comment 12 Tamar Christina 2018-12-12 07:38:28 UTC
Hi David,

Interesting, if you can reproduce the issue on Linux than that makes it easier.

My gitlab username is @Mistuke
Comment 13 David Ledger 2018-12-12 08:08:06 UTC
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&amp;data=02%7C01%7C%7Cfc993a75c8bd4d7dfc8b08d66004d0ab%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636801971127028832&amp;sdata=O4hGTLPAujt7jpYyKj2UY4rOExffLfBXOZ5b%2BD0PHBQ%3D&amp;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.
Comment 14 Tamar Christina 2018-12-12 08:18:52 UTC
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.
Comment 15 David Ledger 2018-12-12 08:21:38 UTC
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&amp;data=02%7C01%7C%7Cdbd0e0d48f48489487e608d6600a7615%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636801995381050253&amp;sdata=TjmwItHJ9Yy2PNsc7R481wueih9y9J7EC12UzRWhlQ8%3D&amp;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.
Comment 16 David Ledger 2018-12-12 08:23:39 UTC
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&amp;data=02%7C01%7C%7Cdbd0e0d48f48489487e608d6600a7615%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636801995381050253&amp;sdata=TjmwItHJ9Yy2PNsc7R481wueih9y9J7EC12UzRWhlQ8%3D&amp;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.
Comment 17 Tamar Christina 2018-12-12 08:26:40 UTC
> Are you able to access it now?

Yup, I'll try to repro now. Thanks!
Comment 18 Tamar Christina 2018-12-12 09:55:21 UTC
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
Comment 19 David Ledger 2018-12-12 11:48:27 UTC
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&amp;data=02%7C01%7C%7Cb15d731f0e1a41b06fa408d66017f02c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636802053264019698&amp;sdata=xH18cr0rgCGdIBFVbguPC2WCtN3j1bEJ0GR3KJRRJNg%3D&amp;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.
Comment 20 Tamar Christina 2018-12-12 12:29:58 UTC
Thanks,

Confirmed, able to reproduce it now. Will take a look.
Comment 21 Tamar Christina 2018-12-12 16:29:11 UTC
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.
Comment 22 David Ledger 2018-12-13 01:59:19 UTC
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&amp;data=02%7C01%7C%7Cc2f08691526d4db6673908d6604ef4bc%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636802289560134947&amp;sdata=D7tZTAXmrosCpuTh9UOS%2BepgSt1G4ohLY0FVy5eZ6Gk%3D&amp;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&amp;data=02%7C01%7C%7Cc2f08691526d4db6673908d6604ef4bc%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636802289560134947&amp;sdata=%2BAiATfI%2BMDFzFiSh6FzxQhqepnlGtq280Qk3dAryqbY%3D&amp;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.
Comment 23 Tamar Christina 2018-12-13 10:17:10 UTC
> 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.
Comment 24 David Ledger 2018-12-13 10:27:41 UTC
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&amp;data=02%7C01%7C%7Cc4d42d5362ab4c12938108d660e42791%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636802930366926937&amp;sdata=xPnBO8%2F%2F44Pa0dnjLrE2mr4XwFPeHw44Va8wIe1mwrE%3D&amp;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.
Comment 25 Tamar Christina 2018-12-13 10:51:28 UTC
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.
Comment 26 Tamar Christina 2018-12-13 10:53:31 UTC
Moved to GCC bugzilla, once libiberty is fixed binutils needs to be synced.
Comment 27 David Ledger 2018-12-14 00:38:29 UTC
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&amp;data=02%7C01%7C%7C0db61d09e5254258ab5608d660e93ae9%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636802952159249682&amp;sdata=5fIzSF6RK6UkpqRH1wFqe2ADTYBq61jmEvKDVirVBoI%3D&amp;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&amp;data=02%7C01%7C%7C0db61d09e5254258ab5608d660e93ae9%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636802952159249682&amp;sdata=1k3%2B1a8os0JApLyE9fvJoeMDMxekvTaeD1p3LsSq1uE%3D&amp;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.
Comment 28 Tamar Christina 2018-12-14 11:01:32 UTC
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.
Comment 29 David Ledger 2018-12-17 04:54:01 UTC
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&amp;data=02%7C01%7C%7C9ad3aa2986c3400b1f8308d661b38527%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636803820988634130&amp;sdata=YbDk3oOCYPAF9ACnvBU0yXaz5AuOf%2FvmxOSuxXJxUt4%3D&amp;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.
Comment 30 Tamar Christina 2018-12-17 16:15:54 UTC
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.
Comment 31 Tamar Christina 2018-12-17 17:35:34 UTC
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.