GCC 8 LTO fails on Windows with -g/-g3

[Liviu Ionescu]

GCC 8-2018-q4
Windows 10 64-bit
Errors:
  ELF section name out of range
  ld: lto-wrapper failed

The project(s) are generated with the GNU MCU Eclipse STM32F4 template.

I tried both C and C++ projects, both fail if I enable LTO, and build properly if I disable LTO.

They also build properly if I remove -g/-g3.

The console reads:

c:/users/ilg/appdata/roaming/gnu tools arm embedded/8-2018-q4/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: error: C:\Users\ilg\AppData\Local\Temp\cc08jQRZdebugobjtem: ELF section name out of range
collect2.exe: error: ld returned 1 exit status
lto-wrapper.exe: fatal error: arm-none-eabi-g++ returned 1 exit status
compilation terminated.
c:/users/ilg/appdata/roaming/gnu tools arm embedded/8-2018-q4/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: error: lto-wrapper failed
collect2.exe: error: ld returned 1 exit status
make: *** [makefile:64: f4b-lto.elf] Error 1
"make all" terminated with exit code 2. Build might be incomplete.

Both the original Arm binary and the similar GNU MCU Eclipse ARM Embedded GCC binary behave the same.

The problem seems to affect only the Windows binary; on Linux and macOS, projects created with exactly the same procedure, pass the build as expected.

Building target: f4b-lto.elf
Invoking: GNU ARM Cross C++ Linker
arm-none-eabi-g++ -mcpu=cortex-m4 -mthumb -mfloat-abi=soft -Os -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -ffreestanding -flto -Wall -Wextra -g -T mem.ld -T libs.ld -T sections.ld -nostartfiles -Xlinker --gc-sections -L"../ldscripts" -Wl,-Map,"f4b-lto.map" --specs=nano.specs -o "f4b-lto.elf" ./system/src/stm32f4-hal/stm32f4xx_hal.o ./system/src/stm32f4-hal/stm32f4xx_hal_cortex.o ./system/src/stm32f4-hal/stm32f4xx_hal_dfsdm.o ./system/src/stm32f4-hal/stm32f4xx_hal_flash.o ./system/src/stm32f4-hal/stm32f4xx_hal_gpio.o ./system/src/stm32f4-hal/stm32f4xx_hal_iwdg.o ./system/src/stm32f4-hal/stm32f4xx_hal_pwr.o ./system/src/stm32f4-hal/stm32f4xx_hal_rcc.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_stm32f4xx.o ./system/src/cmsis/vectors_stm32f407xx.o ./src/BlinkLed.o ./src/Timer.o ./src/_initialize_hardware.o ./src/_write.o ./src/main.o ./src/stm32f4xx_hal_msp.o
Finished building target: f4b-lto.elf

[Liviu Ionescu (ilg)]

I did further tests and the previous version (7-2018-q2-update) builds my projects (both C and C++) properly with -flto.

So the problem was introduced in the latest release.

I would call this a major bug.

[Liviu Ionescu (ilg)]

Even more tests revealed the problem to be related to the presence of debug information.

With -g/-g3 it fails on Windows and works on Linux/macOS.

Without any -g* it seems ok on all platforms.

Previous versions seem ok on all platforms.

[Liviu Ionescu (ilg)]

It is easy to reproduce this bug, create an empty main.c and try to compile it with -g or -g3:

C:\Users\ilg\tmp>"C:\Users\ilg\AppData\Roaming\GNU Tools ARM Embedded\8-2018-q4\bin\arm-none-eabi-gcc.exe" -flto -g main.c
c:/users/ilg/appdata/roaming/gnu tools arm embedded/8-2018-q4/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: C:\Users\ilg\AppData\Local\Temp\cck5e5XRdebugobjtem: file not recognized: file truncated
collect2.exe: error: ld returned 1 exit status
lto-wrapper.exe: fatal error: C:\Users\ilg\AppData\Roaming\GNU Tools ARM Embedded\8-2018-q4\bin\arm-none-eabi-gcc.exe returned 1 exit status
compilation terminated.
c:/users/ilg/appdata/roaming/gnu tools arm embedded/8-2018-q4/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: error: lto-wrapper failed
collect2.exe: error: ld returned 1 exit status

C:\Users\ilg\tmp>"C:\Users\ilg\AppData\Roaming\GNU Tools ARM Embedded\8-2018-q4\bin\arm-none-eabi-gcc.exe" -flto -g3 main.c
c:/users/ilg/appdata/roaming/gnu tools arm embedded/8-2018-q4/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Users\ilg\AppData\Local\Temp\ccg9waOldebugobjtem has a corrupt section with a size (a0d66) larger than the file size
c:/users/ilg/appdata/roaming/gnu tools arm embedded/8-2018-q4/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: C:\Users\ilg\AppData\Local\Temp\ccg9waOldebugobjtem: invalid string offset 2048 >= 22975072851460187 for section `(null)'
c:/users/ilg/appdata/roaming/gnu tools arm embedded/8-2018-q4/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: C:\Users\ilg\AppData\Local\Temp\ccg9waOldebugobjtem: invalid string offset 2048 >= 22975072851460187 for section `(null)'
c:/users/ilg/appdata/roaming/gnu tools arm embedded/8-2018-q4/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: C:\Users\ilg\AppData\Local\Temp\ccg9waOldebugobjtem: invalid string offset 12032 >= 22975072851460187 for section `(null)'
c:/users/ilg/appdata/roaming/gnu tools arm embedded/8-2018-q4/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: C:\Users\ilg\AppData\Local\Temp\ccg9waOldebugobjtem: invalid string offset 16640 >= 22975072851460187 for section `(null)'
c:/users/ilg/appdata/roaming/gnu tools arm embedded/8-2018-q4/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: C:\Users\ilg\AppData\Local\Temp\ccg9waOldebugobjtem: invalid string offset 16640 >= 22975072851460187 for section `(null)'
collect2.exe: error: ld returned 5 exit status
lto-wrapper.exe: fatal error: C:\Users\ilg\AppData\Roaming\GNU Tools ARM Embedded\8-2018-q4\bin\arm-none-eabi-gcc.exe returned 1 exit status
compilation terminated.
c:/users/ilg/appdata/roaming/gnu tools arm embedded/8-2018-q4/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: error: lto-wrapper failed
collect2.exe: error: ld returned 1 exit status

[Liviu Ionescu (ilg)]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89183

[Liviu Ionescu (ilg)]

The problem was fixed upstream and will probably be included in 8.3.

[Joey Ye (jinyun-ye)]

Fixed in 8.3-2019-08 release

[stewo (wolfer-y)]

Ich bin bis 28.10. nicht im Haus und kann Ihre Nachricht daher leider nicht bearbeiten. In dringenden Fällen wenden Sie sich bitte an <email address hidden> bzw. für technische Fragen an <email address hidden>.

I am out of office until October 28th and won't be able to read your message. In urgent cases, please refer to <email address hidden> or for technical questions to <email address hidden>.

Mit freundlichen Grüßen / Best regards

Steffen Wolfer

--
Dipl.-Inform. Steffen Wolfer
Software Engineer Embedded Systems

WEISS ROBOTICS GmbH & Co. KG
Karl-Heinrich-Käferle-Str. 8
D-71640 Ludwigsburg, Germany

Phone: [phone]
Fax: [phone]
http://www.weiss-robotics.com

Sitz der Gesellschaft: Ludwigsburg
Registergericht Stuttgart, HRA725006

Pers. haftende Gesellschafterin:
Weiss Robotics Verwaltungs-GmbH, Sitz Ludwigsburg
Registergericht Stuttgart, HRB73310
Geschäftsführer: Dr. Karsten Weiß

Fixed in 8.3-2019-08 release

** Changed in: gcc-arm-embedded
       Status: New => Fix Released

--
You received this bug notification because you are subscribed to GNU Arm
Embedded Toolchain.
Matching subscriptions: Älles
https://bugs.launchpad.net/bugs/1814397

Title:
  GCC 8 LTO fails on Windows with -g/-g3

Status in GNU Arm Embedded Toolchain:
  Fix Released

Bug description:
  GCC 8-2018-q4
  Windows 10 64-bit
  Errors:
    ELF section name out of range
    ld: lto-wrapper failed

  The project(s) are generated with the GNU MCU Eclipse STM32F4
  template.

  I tried both C and C++ projects, both fail if I enable LTO, and build
  properly if I disable LTO.

  They also build properly if I remove -g/-g3.

  The console reads:

  c:/users/ilg/appdata/roaming/gnu tools arm embedded/8-2018-q4/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: error: C:\Users\ilg\AppData\Local\Temp\cc08jQRZdebugobjtem: ELF section name out of range
  collect2.exe: error: ld returned 1 exit status
  lto-wrapper.exe: fatal error: arm-none-eabi-g++ returned 1 exit status
  compilation terminated.
  c:/users/ilg/appdata/roaming/gnu tools arm embedded/8-2018-q4/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: error: lto-wrapper failed
  collect2.exe: error: ld returned 1 exit status
  make: *** [makefile:64: f4b-lto.elf] Error 1
  "make all" terminated with exit code 2. Build might be incomplete.

  Both the original Arm binary and the similar GNU MCU Eclipse ARM
  Embedded GCC binary behave the same.

  The problem seems to affect only the Windows binary; on Linux and
  macOS, projects created with exactly the same procedure, pass the
  build as expected.

  Building target: f4b-lto.elf
  Invoking: GNU ARM Cross C++ Linker
  arm-none-eabi-g++ -mcpu=cortex-m4 -mthumb -mfloat-abi=soft -Os -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -ffreestanding -flto -Wall -Wextra -g -T mem.ld -T libs.ld -T sections.ld -nostartfiles -Xlinker --gc-sections -L"../ldscripts" -Wl,-Map,"f4b-lto.map" --specs=nano.specs -o "f4b-lto.elf" ./system/src/stm32f4-hal/stm32f4xx_hal.o ./system/src/stm32f4-hal/stm32f4xx_hal_cortex.o ./system/src/stm32f4-hal/stm32f4xx_hal_dfsdm.o ./system/src/stm32f4-h...

[Liviu Ionescu (ilg)]

Hi Joey,

I saw your latest release includes Aarch64 binaries, and I plan to add them to my xPack distribution too (https://xpack.github.io/arm-none-eabi-gcc/).

I took a look at the source tarball but the documentation and the scripts do not clearly explain how the binaries were built.

Apparently you did not cross compile them on an Intel machine, but natively on an AArch64 Ubuntu.

Can you confirm this?

If not a big secret, can you tell me what hardware was it?

And another question, any reason for not cross compiling on an Intel box?

Thank you,

Liviu

[Joey Ye (jinyun-ye)]

Hi Liviu,

Sorry our build documentation missed out the instructions. AArch64 Linux build is almost the same to the x86 Linux build.

The binaries were built on an AArch64 Ubuntu 16.08 machine. The underlying hardware doesn't really matter as long as they are at least armv8.0.

Thanks,
Joey

> -----Original Message-----
> From: <email address hidden> <gnu-rm-
> <email address hidden>> On Behalf Of Liviu Ionescu
> Sent: 03 December 2019 22:57
> To: gnu-rm-support <email address hidden>
> Subject: [Gnu-rm-support] [Bug 1814397] 9-2019-q4-major Aarch64 binaries
>
> Hi Joey,
>
> I saw your latest release includes Aarch64 binaries, and I plan to add them to
> my xPack distribution too (https://xpack.github.io/arm-none-
> eabi-gcc/).
>
> I took a look at the source tarball but the documentation and the scripts do
> not clearly explain how the binaries were built.
>
> Apparently you did not cross compile them on an Intel machine, but natively
> on an AArch64 Ubuntu.
>
> Can you confirm this?
>
> If not a big secret, can you tell me what hardware was it?
>
>
> And another question, any reason for not cross compiling on an Intel box?
>
>
> Thank you,
>
> Liviu
>
> --
> You received this bug notification because you are a member of GCC Arm
> Embedded Maintainers, which is subscribed to GNU Arm Embedded
> Toolchain.
> Matching subscriptions: GCC ARM embedded bug activity
> https://bugs.launchpad.net/bugs/1814397
>
> Title:
> GCC 8 LTO fails on Windows with -g/-g3
>
> Status in GNU Arm Embedded Toolchain:
> Fix Released
>
> Bug description:
> GCC 8-2018-q4
> Windows 10 64-bit
> Errors:
> ELF section name out of range
> ld: lto-wrapper failed
>
> The project(s) are generated with the GNU MCU Eclipse STM32F4
> template.
>
> I tried both C and C++ projects, both fail if I enable LTO, and build
> properly if I disable LTO.
>
> They also build properly if I remove -g/-g3.
>
> The console reads:
>
> c:/users/ilg/appdata/roaming/gnu tools arm embedded/8-2018-
> q4/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe:
> error: C:\Users\ilg\AppData\Local\Temp\cc08jQRZdebugobjtem: ELF section
> name out of range
> collect2.exe: error: ld returned 1 exit status
> lto-wrapper.exe: fatal error: arm-none-eabi-g++ returned 1 exit status
> compilation terminated.
> c:/users/ilg/appdata/roaming/gnu tools arm embedded/8-2018-
> q4/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe:
> error: lto-wrapper failed
> collect2.exe: error: ld returned 1 exit status
> make: *** [makefile:64: f4b-lto.elf] Error 1
> "make all" terminated with exit code 2. Build might be incomplete.
>
> Both the original Arm binary and the similar GNU MCU Eclipse ARM
> Embedded GCC binary behave the same.
>
> The problem seems to affect only the Windows binary; on Linux and
> macOS, projects created with exactly the same procedure, pass the
> build as expected.
>
> Building target: f4b-lto.elf
> Invoking: GNU ARM Cross C++ Linker
> arm-none-eabi-g++ -mcpu=corte...