When running llvm-dwarfdump --verify Application.axf I get many "DIE address ranges are not contained in its parent's ranges" and "DIEs have overlapping address ranges" errors.
llvm-dwarfdump --verify Application.axf
DIE address ranges are not contained in its parent's ranges
DIEs have overlapping address ranges
The first one seems to be due to incomplete entries in the .debug_ranges section, e.g.:
error: DIE address ranges are not contained in its parent's ranges:
DW_AT_producer ("Component: Arm Compiler for Embedded 6.18 Tool: armclang [5e4cc700]")
Also, there are many entries in .debug_ranges that only contain <End of list>.
<End of list>
The second error is due to many functions reported to be located at address 0:
error: DIEs have overlapping address ranges:
DW_AT_type (0x000f7203 "bool")
DW_AT_abstract_origin (0x000f2698 "_ZN4SomethingEi")
I believe this is the reason that various implementations of the addr2line utility, GDB and LLDB cannot resolve the source code line numbers for certain addresses.
Might this be a bug in Arm Compiler 6 or am I missing something?
Any help is highly appreciated.
Turns out that when armlink removes code it will set debug information references pointing to it to "dangling debug address" which is 0 by default. This seems to be allowed by the (DWARF 5) standard which reads:
A bounded range entry whose beginning and ending address offsets are equal
(including zero) indicates an empty range and may be ignored.
So, I understand that DWARF parsers technically should ignore the entries. But, I guess that would make parsing harder as they can be mistaken for "end of list" entries.
The "dangling debug address" can be changed with the --dangling-debug-address linker option, which fixes debugging with e.g. GDB or resolving addresses with addr2line.
Anyway, IMHO the debug info is not ideal this way as one still gets errors when running e.g. llvm-dwarfdump --verify which is quite ugly.