On Thu, May 10, 2018 at 11:32 PM, Freddie Chopin <freddie_cho...@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
