Dwarf 4 debug fission rangelist issue

[jeremy-rifkin]

Hi, I'm running into an issue with range lists under -gsplit-dwarf -gdwarf-4 which as far as I can tell is either a libdwarf bug or a gcc bug.

In this case I'm trying to find which function has the program counter 0x188ad. It should be stacktrace_basic, which objdump confirms:

0000000000018860 <_Z16stacktrace_basicv>:
   18860:   f3 0f 1e fa             endbr64
   18864:   41 57                   push   r15
    ....
   188a1:   48 89 c7                mov    rdi,rax
   188a4:   48 89 44 24 10          mov    QWORD PTR [rsp+0x10],rax
   188a9:   e8 72 cd fe ff          call   5620 <_ZN8cpptrace14generate_traceEmm@plt>
   188ae:   48 8b 44 24 58          mov    rax,QWORD PTR [rsp+0x58]

However, the rangelist as reported by libdwarf doesn't contain this address:

$ path/to/dwarfdump -i -M -G  -vv  --file-tied=unittest test/CMakeFiles/unittest.dir/unit/stacktrace.cpp.dwo
...
< 1><0x0008b7ce GOFF=0x0008b7ce>    DW_TAG_subprogram <abbrev 424 ABGOFF = 0x00002188 count = 0x0000000a>
                                      DW_AT_external              yes(1) <form DW_FORM_flag_present 25>
                                      DW_AT_name                  (indexed string: 0x000014e4)stacktrace_basic <form DW_FORM_GNU_str_index 7938>
                                      DW_AT_decl_file             0x00000007 <form DW_FORM_data1 11>
                                      DW_AT_decl_line             0x0000001f <form DW_FORM_data1 11>
                                      DW_AT_decl_column           0x0000001f <form DW_FORM_data1 11>
                                      DW_AT_linkage_name          (indexed string: 0x00000911)_Z16stacktrace_basicv <form DW_FORM_GNU_str_index 7938>
                                      DW_AT_ranges                0x00017470 <form DW_FORM_sec_offset 23>
  ranges: 2 at .debug_ranges offset 95344 (0x00017470) (32 bytes)
   [ 0] range entry    0x00005c1e 0x00005c2f
   [ 1] range end      0x00000000 0x00000000
                                      DW_AT_frame_base            len 0x0001: 0x9c:  <form DW_FORM_exprloc 24>
                                          DW_OP_call_frame_cfa
                                      DW_AT_GNU_all_tail_call_sites yes(1) <form DW_FORM_flag_present 25>
                                      DW_AT_sibling               <0x000928a5 GOFF=0x000928a5> <form DW_FORM_ref4 19>

I'm not sure whether this is an issue with libdwarf's parsing of the range list or if gcc isn't emitting the correct information.

I have attached the relevant .dwo file and the tied file in case it can be of help: unittest_and_stacktrace_dwo.zip

Under most of my testing with -gsplit-dwarf -gdwarf-4 I've found everything to work splendidly, I think this is the only time I've ran into issues.

All is fine under dwarf 5.

[davea42]

I have a DWARF committee meeting in 90 minutes and then a long-standing appointment so it will be 4-5 hours before I can really look at this.

And as it happens I am actually working on improving rnglists and reporting thereof.

I downloaded the DWARF4 example. Thank you. I'll get back to you in a few hours.

[davea42]

Have corrected aspects of rnglists, but as yet this will not help you. Now to have dwarfdump report such better so one can easily verify by hand whether rnglists are handled properly. Whether a step three is needed is ... unclear. More tomorrow.

[davea42]

DWARF4 DW_AT GNU_ranges_base was being ignored, I forgot to include it in the merge step (merge from the tied object to the dwo/dwp object). With that included things look pretty good. I have some testing to do now to ensure nothing breaks.

[davea42]

Have pushed these changes. Doing additional testing and tidying up. LGTM.

[jeremy-rifkin]

Awesome! Thank you so much Dave as always for the quick reply and fix!

[jeremy-rifkin]

I have confirmed the new changes work locally for me, at least for range lists emitted by gcc. I am bumping into issues with clang and I'll take the time to look into them tomorrow.

[jeremy-rifkin]

Ok, I have looked at the issue with clang and have found that it's an issue on my end. All good, thank you again so much!

[davea42]

Problem solved, so closing.