Re: LTO vs GCC 8

[Richard Biener <richard.guenther@gmail.com>]

On Thu, May 10, 2018 at 11:32 PM, Freddie Chopin <freddie_chopin@op.pl> wrote:
> Hi!
>
> In one of my embedded projects I have an option to enable LTO. This was
> working more or less fine for GCC 6 and GCC 7, however for GCC 8.1.0
> (and binutils 2.30) - with the same set of options - I see something
> like this
>
> -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --
>
> $ arm-none-eabi-g++ -Wall -Wextra -Wshadow -std=gnu++11 -mcpu=cortex-m4
> -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -g -ggdb3 -O2 -flto -ffat-
> lto-objects -fno-use-cxa-atexit -ffunction-sections -fdata-sections
> -fno-rtti -fno-exceptions ... [include paths] ... -MD -MP -c
> test/TestCase.cpp -o output/test/TestCase.o
>
> $ arm-none-eabi-g++  -mcpu=cortex-m4 -mthumb -mfloat-abi=hard
> -mfpu=fpv4-sp-d16 -g -O2 -flto -fuse-linker-plugin -Wl,-
> Map=output/test/distortosTest.map,--cref,--gc-sections
> -Toutput/ST_STM32F4DISCOVERY.preprocessed.ld ... [a lot of objects] ...
> -Wl,--whole-archive -l:output/libdistortos.a -Wl,--no-whole-archive -o
> output/test/distortosTest.elf
>
> $ arm-none-eabi-objdump --demangle -S output/test/distortosTest.elf >
> output/test/distortosTest.lss
> arm-none-eabi-objdump: Dwarf Error: Could not find abbrev number 167.
> arm-none-eabi-objdump: Dwarf Error: found dwarf version '37', this
> reader only handles version 2, 3, 4 and 5 information.
> arm-none-eabi-objdump: Dwarf Error: found dwarf version '6144', this
> reader only handles version 2, 3, 4 and 5 information.
> arm-none-eabi-objdump: Dwarf Error: found dwarf version '4864', this
> reader only handles version 2, 3, 4 and 5 information.
> ...
> ... (a lot more)
> ...
>
> -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --
>
> As you see, the errors apear only when I try to generate an assembly
> dump. I'm not sure whether the problem is in GCC or in objdump, but
> when I have an .elf file produced (with the same options) by gcc 7.3.0,
> then this new version of objdump doesn't produce any errors. What is
> also interesting is that the errors are not fatal - the exit code of
> the process is 0.
>
> What is also interesing is that this problem doesn't appear in a
> trivial test case, so I suspect this is something more subtle. I did
> not try to narrow it down into a shareable test case, but if you have
> no hints then maybe I'll try to do that.
>
> Any ideas what may be the problem here? Especially do you know whether
> I should be asking this question here or maybe on binutils mailing
> list?

Hmm, can you try without --gc-sections?  "Old" GNU ld versions have
a bug that wrecks debug info (sourceware PR20882).

Richard.

> Thanks in advance!
>
> Regards,
> FCh