llvm-dwarfdump doesn't understand call-site info

[Trass3r]

Bugzilla Link	41846
Version	8.0
OS	All
CC	@JDevlieghere,@walkerkd,@pogo59

Extended Description

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

built with Ubuntu 19.04 arm-gcc (7.3.1):

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

llvm-dwarfdump-8 --verify firmware.elf

[Trass3r]

Gives lots of errors like shown below.
At least the invalid DWARF expression ones look like the tool does not support certain gcc opcodes. (?)

error: DIE contains invalid DWARF expression:

0x00000949: DW_TAG_formal_parameter
DW_AT_name ("fn")
DW_AT_decl_file ("/build/newlib-hTUQk9/newlib-3.1.0.20181231/build_nano/arm-none-eabi/thumb/v7e-m/newlib/libc/stdlib/../../../../../../../newlib/libc/stdlib/atexit.c")
DW_AT_decl_line (56)
DW_AT_type (0x00000326 "void()*")
DW_AT_location (0x00000000
[0x00008104, 0x0000810c): DW_OP_reg0
[0x0000810c, 0x0000810f): DW_OP_reg1
[0x0000810f, 0x00008110): 01 50 9f)

error: DIE with tag DW_TAG_GNU_call_site has DW_AT_abstract_origin that points to DIE with incompatible tag DW_TAG_subprogram

0x00003506: DW_TAG_GNU_call_site
DW_AT_low_pc (0x00000000000082c0)
DW_AT_abstract_origin (0x00003518 "malloc")

error: DIE with tag DW_TAG_variable is missing type attribute:

0x00003dbf: DW_TAG_variable
DW_AT_specification (0x00003d9c "_global_atexit")
DW_AT_location (DW_OP_addr 0x184c0)

error: DIE contains invalid DWARF expression:

0x00002b7e: DW_TAG_variable
DW_AT_name ("d")
DW_AT_decl_file ("/build/newlib-hTUQk9/newlib-3.1.0.20181231/build_nano/arm-none-eabi/thumb/v7e-m/newlib/libc/string/../../../../../../../newlib/libc/string/memset.c")
DW_AT_decl_line (48)
DW_AT_type (0x00001dad "unsigned int")
DW_AT_location (0x00000284
[0x000081b4, 0x00008234): DW_OP_breg1 +0, DW_OP_const1u 0xff, DW_OP_and, DW_OP_stack_value
[0x00008234, 0x00008242): 01 51 08 ff 1a 9f
[0x00008242, 0x00008248): DW_OP_breg1 +0, DW_OP_const1u 0xff, DW_OP_and, DW_OP_stack_value)

[pogo59]

It looks like the source you quoted isn't where the object file came from:
0x00000949: DW_TAG_formal_parameter
DW_AT_name ("fn")
but your source doesn't have any functions with any parameters.

Regardless, yeah, LLVM doesn't do the standard call-site features yet
(although there's work in progress) and once that's in, I expect we'll
add the GNU versions of the tags and whatnot to the dumper.

I've updated the bug title to be more specific to what's missing.
Thanks for the report.

[Trass3r]

These symbols come from newlib actually.
So what about those variable ___location decoding errors?
Do they belong to callsite info too?

[pogo59]

So what about those variable ___location decoding errors?
Do they belong to callsite info too?

Ah, missed those. Both of the erroneous expressions start with "01"
which is not defined, and incredibly unlikely to be a GNU opcode.
It may be that llvm-dwarfdump is misinterpreting something in the
location list, and so trying to treat those as separate expressions
instead of something more sensible.

What does "objdump -Wi" report for these variables?

[Trass3r]

objdump -Wi

[pogo59]

Created attachment 21962 [details]
objdump -Wi

Thanks--it looks like -Wi reports
<2><95e>: Abbrev Number: 32 (DW_TAG_formal_parameter)
<95f> DW_AT_name : fn
<962> DW_AT_decl_file : 1
<963> DW_AT_decl_line : 56
<964> DW_AT_type : <0x33b>
<968> DW_AT_location : 0x0 (___location list)

and doesn't follow the reference to .debug_loc. Sorry, I forgot objdump
didn't do that! Can you also provide 'objdump -Wo' for the same object.

[Trass3r]

objdump -Wo

[pogo59]

Created attachment 21964 [details]
objdump -Wo

Thanks. It looks like GNU really did decide to use opcode 0x01 for
DW_OP_GNU_entry_value, which is an uncharacteristic violation of the
DWARF standard. But at least we know now.

So, everything you have reported falls under the general heading of
call-site information. LLVM doesn't (yet) support generating it, but
it is reasonable to ask llvm-dwarfdump to be able to decode it, given
that gcc is able to produce it (even if it's violating the standard).

The actual reading/decoding happens in LLVM's DebugInfo library, so
switching the component accordingly. Thanks for the report!

[Trass3r]

Yes looks like quite a while ago: https://bugzilla.redhat.com/show_bug.cgi?id=688090

[jryans]

LLVM now supports the call site DWARF feature overall, and I've also verified that llvm-dwarfdump 20.1.0 verifies the example here successfully, so I believe we can call this fixed.