Dwarf Error: Could not find abbrev number

[freddiechopin]

Dwarf Error: Could not find abbrev number

[Trass3r]

I could finally reproduce it without any C lib influence and then with x86 gcc 9. Thankfully it's readily available in Ubuntu 19.04.
A genuine regression in gcc 9.0.
Thanks for your help!

[FreddieChopin]

Your code produces multiple warnings.

main.cpp:2:5: warning: declaration of 'int _exit()' conflicts with built-in declaration 'void _exit(int)' [-Wbuiltin-declaration-mismatch]
    2 | int _exit(){}
      |     ^~~~~
main.cpp: In function 'int _exit()':
main.cpp:2:13: warning: no return statement in function returning non-void [-Wreturn-type]
    2 | int _exit(){}
      |             ^
main.cpp: In member function 'int HardwareSerial3::available()':
main.cpp:5:19: warning: no return statement in function returning non-void [-Wreturn-type]
    5 | int available() { }
      |                   ^

After fixing all of them:

extern "C"
void _exit(int){ while(1); }
int main() {}
class HardwareSerial3 {
void available() {}
};
void yield() {}

$ arm-none-eabi-g++ -o main.cpp.o -c -fno-exceptions -felide-constructors -fno-rtti -std=gnu++14 -Wno-error=narrowing -flto -g -ffunction-sections -fdata-sections -mthumb -mcpu=cortex-m4 -nostdlib -O2 main.cpp
$ arm-none-eabi-g++ -o firmware.elf -g -Wl,--gc-sections,--relax -mthumb -mcpu=cortex-m4 -O2 --specs=nano.specs -Wl,--start-group main.cpp.o -lm -lstdc++ -Wl,--end-group
$ arm-none-eabi-nm -ClS --radix=d --size-sort firmware.elf
00099761 00000001 B __lock___arc4random_mutex	/home/freddie/bleeding-edge-toolchain/sources/newlib-3.1.0/newlib/libc/misc/lock.c:103
00099760 00000001 B __lock___atexit_recursive_mutex	/home/freddie/bleeding-edge-toolchain/sources/newlib-3.1.0/newlib/libc/misc/lock.c:97
00099765 00000001 B __lock___at_quick_exit_mutex	/home/freddie/bleeding-edge-toolchain/sources/newlib-3.1.0/newlib/libc/misc/lock.c:98
00099766 00000001 B __lock___dd_hash_mutex	/home/freddie/bleeding-edge-toolchain/sources/newlib-3.1.0/newlib/libc/misc/lock.c:102
00099762 00000001 B __lock___env_recursive_mutex	/home/freddie/bleeding-edge-toolchain/sources/newlib-3.1.0/newlib/libc/misc/lock.c:100
00099764 00000001 B __lock___malloc_recursive_mutex	/home/freddie/bleeding-edge-toolchain/sources/newlib-3.1.0/newlib/libc/misc/lock.c:99
00099768 00000001 B __lock___sfp_recursive_mutex	/home/freddie/bleeding-edge-toolchain/sources/newlib-3.1.0/newlib/libc/misc/lock.c:96
00099763 00000001 B __lock___sinit_recursive_mutex	/home/freddie/bleeding-edge-toolchain/sources/newlib-3.1.0/newlib/libc/misc/lock.c:95
00099767 00000001 B __lock___tz_mutex	/home/freddie/bleeding-edge-toolchain/sources/newlib-3.1.0/newlib/libc/misc/lock.c:101
00033068 00000002 T _exit	/tmp/main.cpp:2
00033596 00000002 T __retarget_lock_acquire_recursive
00033598 00000002 T __retarget_lock_release
00033600 00000002 T __retarget_lock_release_recursive
00099272 00000004 D __atexit_recursive_mutex	/home/freddie/bleeding-edge-toolchain/sources/newlib-3.1.0/newlib/libc/stdlib/__call_atexit.c:17
00099444 00000004 B _global_atexit
00033616 00000004 R _global_impure_ptr
00032820 00000004 T main	/tmp/main.cpp:3
00033072 00000012 T atexit	/home/freddie/bleeding-edge-toolchain/sources/newlib-3.1.0/newlib/libc/include/stdlib.h:76
00033196 00000016 T memset	/home/freddie/bleeding-edge-toolchain/sources/newlib-3.1.0/newlib/libc/include/string.h:33
00032780 00000040 T exit	/home/freddie/bleeding-edge-toolchain/sources/newlib-3.1.0/newlib/libc/include/stdlib.h:93
00033084 00000040 T __libc_fini_array	/home/freddie/bleeding-edge-toolchain/sources/newlib-3.1.0/newlib/libc/misc/fini.c:26
00033124 00000072 T __libc_init_array	/home/freddie/bleeding-edge-toolchain/sources/newlib-3.1.0/newlib/libc/misc/init.c:30
00099176 00000096 d impure_data	/home/freddie/bleeding-edge-toolchain/sources/newlib-3.1.0/newlib/libc/reent/impure.c:23
00099304 00000140 b _global_atexit0	/home/freddie/bleeding-edge-toolchain/sources/newlib-3.1.0/newlib/libc/stdlib/__atexit.c:57
00033408 00000188 T __call_exitprocs	/home/freddie/bleeding-edge-toolchain/sources/newlib-3.1.0/newlib/libc/stdlib/__call_atexit.c:70
00033212 00000196 T __register_exitproc	/home/freddie/bleeding-edge-toolchain/sources/newlib-3.1.0/newlib/libc/stdlib/__atexit.c:68
00099448 00000312 B __sf

Even if there is a regressions, the error you see is not fatal (echo $? prints 0) and does not actually cause any problem (as the error message is printed to stderr, not stdout). Earlier versions of bleeding-edge-toolchain (gcc 6, gcc 7, gcc 8) also don't print this error message, therefore I think the problem is not related to the way the toolchain is built, but most likely to something within binutils.

Edit: Sorry for closing, wrong button.

[Trass3r]

Your code produces multiple warnings.

It's simply reduced code. The minimal version with the linker script still in use requires multiple source files.

Even if there is a regressions, the error you see is not fatal (echo $? prints 0) and does not actually cause any problem

In the real code it does I think. nm does not show the source paths for most symbols. The debug info seems to be corrupt.
llvm-dwarfdump --verify does not really help though as it produces lots of errors for any arm-gcc output.
I haven't tried gdb yet as it requires qemu.

Earlier versions of bleeding-edge-toolchain (gcc 6, gcc 7, gcc 8) also don't print this error message, therefore I think the problem is not related to the way the toolchain is built, but most likely to something within binutils.

Thanks for trying, that narrows it down to gcc or binutils.

[FreddieChopin]

It's simply reduced code. The minimal version with the linker script still in use requires multiple source files.

You can upload it anyway, with a Makefile or shell script or CMake or whatever (;

In the real code it does I think. nm does not show the source paths for most symbols.

Earlier versions of gcc also don't show all paths for symbols, just as the "fixed" output I posted above. For example with GCC 8 (arm-none-eabi-gcc-8.3.0-190223):

$ arm-none-eabi-nm -ClS --radix=d --size-sort firmware.elf
00099753 00000001 B __lock___arc4random_mutex	/home/freddie/bleeding-edge-toolchain/sources/newlib-3.1.0/newlib/libc/misc/lock.c:103
00099752 00000001 B __lock___atexit_recursive_mutex	/home/freddie/bleeding-edge-toolchain/sources/newlib-3.1.0/newlib/libc/misc/lock.c:97
00099757 00000001 B __lock___at_quick_exit_mutex	/home/freddie/bleeding-edge-toolchain/sources/newlib-3.1.0/newlib/libc/misc/lock.c:98
00099758 00000001 B __lock___dd_hash_mutex	/home/freddie/bleeding-edge-toolchain/sources/newlib-3.1.0/newlib/libc/misc/lock.c:102
00099754 00000001 B __lock___env_recursive_mutex	/home/freddie/bleeding-edge-toolchain/sources/newlib-3.1.0/newlib/libc/misc/lock.c:100
00099756 00000001 B __lock___malloc_recursive_mutex	/home/freddie/bleeding-edge-toolchain/sources/newlib-3.1.0/newlib/libc/misc/lock.c:99
00099760 00000001 B __lock___sfp_recursive_mutex	/home/freddie/bleeding-edge-toolchain/sources/newlib-3.1.0/newlib/libc/misc/lock.c:96
00099755 00000001 B __lock___sinit_recursive_mutex	/home/freddie/bleeding-edge-toolchain/sources/newlib-3.1.0/newlib/libc/misc/lock.c:95
00099759 00000001 B __lock___tz_mutex	/home/freddie/bleeding-edge-toolchain/sources/newlib-3.1.0/newlib/libc/misc/lock.c:101
00033588 00000002 T __retarget_lock_acquire_recursive
00033590 00000002 T __retarget_lock_release
00033592 00000002 T __retarget_lock_release_recursive
00099264 00000004 D __atexit_recursive_mutex	/home/freddie/bleeding-edge-toolchain/sources/newlib-3.1.0/newlib/libc/stdlib/__call_atexit.c:17
00099436 00000004 B _global_atexit
00033608 00000004 R _global_impure_ptr
00032820 00000004 T main	/tmp/main.cpp:3
00033068 00000012 T atexit	/home/freddie/bleeding-edge-toolchain/sources/newlib-3.1.0/newlib/libc/include/stdlib.h:76
00033192 00000016 T memset	/home/freddie/bleeding-edge-toolchain/sources/newlib-3.1.0/newlib/libc/include/string.h:33
00032780 00000040 T exit	/home/freddie/bleeding-edge-toolchain/sources/newlib-3.1.0/newlib/libc/include/stdlib.h:93
00033080 00000040 T __libc_fini_array	/home/freddie/bleeding-edge-toolchain/sources/newlib-3.1.0/newlib/libc/misc/fini.c:26
00033120 00000072 T __libc_init_array	/home/freddie/bleeding-edge-toolchain/sources/newlib-3.1.0/newlib/libc/misc/init.c:30
00099168 00000096 d impure_data	/home/freddie/bleeding-edge-toolchain/sources/newlib-3.1.0/newlib/libc/reent/impure.c:23
00099296 00000140 b _global_atexit0	/home/freddie/bleeding-edge-toolchain/sources/newlib-3.1.0/newlib/libc/stdlib/__atexit.c:57
00033404 00000184 T __call_exitprocs	/home/freddie/bleeding-edge-toolchain/sources/newlib-3.1.0/newlib/libc/stdlib/__call_atexit.c:70
00033208 00000196 T __register_exitproc	/home/freddie/bleeding-edge-toolchain/sources/newlib-3.1.0/newlib/libc/stdlib/__atexit.c:68
00099440 00000312 B __sf

Would you consider output above as correct or not?

[Trass3r]

I think it has to do with the LTO early debug info changes. If I remove -g from the compilation commands and only keep it in the linker commandline, everything is fine.

00002976 00000172 t delay       teensy3/pins_teensy.c:1195
00001620 00000224 t uart0_status_isr    teensy3/serial1.c:509
00001396 00000224 t uart1_status_isr    teensy3/serial2.c:499
00003148 00000272 t _init_Teensyduino_internal_ teensy3/pins_teensy.c:520
00000000 00000444 T _VectorsFlash       teensy3/mk20dx128.c:268
536838656 00000444 B _VectorsRam        teensy3/mk20dx128.c:265
00000444 00000488 t ResetHandler        teensy3/mk20dx128.c:690
00002260 00000580 t usb_init    teensy3/usb_dev.c:1109
536839100 00000864 B usb_buffer_memory  teensy3/usb_mem.c:39
00003424 00002520 t usb_isr     teensy3/usb_dev.c:86

With -g everywhere debug info is corrupt:

00002976 00000172 t delay
00001620 00000224 t uart0_status_isr
00001396 00000224 t uart1_status_isr
00003148 00000272 t _init_Teensyduino_internal_
00000000 00000444 T _VectorsFlash       teensy3/kinetis.h:5858
536838656 00000444 B _VectorsRam
00000444 00000488 t ResetHandler
00002260 00000580 t usb_init
536839100 00000864 B usb_buffer_memory
00003424 00002520 t usb_isr

[FreddieChopin]

If it has something to do with both LTO and debugging, then comparing with earlier versions of GCC and/or toolchain has little value - from what I remember earlier versions of GCC had a lot of problems with producing usable debug info for code optimized with LTO. Once I tried it, debugging such executable was practically impossible. Even you mentioned that this was fixed in gcc 8, so this would be probably the only version which can be compared to the current one in this regards.

BTW - if you use Windows, you can download earlier releases of the toolchain from my website and compare the behaviour yourself - see the README.md file for links.