[PATCH] D96045: [llvm-dwarfdump][locstats] Unify handling of inlined vars with no loc

Wed Apr 14 05:13:41 PDT 2021

djtodoro added a comment.

In D96045#2688025 <https://reviews.llvm.org/D96045#2688025>, @dblaikie wrote:

> In D96045#2685000 <https://reviews.llvm.org/D96045#2685000>, @djtodoro wrote:
>
>> In D96045#2684570 <https://reviews.llvm.org/D96045#2684570>, @dblaikie wrote:
>>
>>> In D96045#2678117 <https://reviews.llvm.org/D96045#2678117>, @rdhindsa wrote:
>>>
>>>> After moving the variable InlinedFnsToBeProcessed to inside the for loop, I noticed a difference in two dwarfdump statistics for a quite large binary with fission=yes:
>>>>
>>>> #variables processed by location statistics
>>>> #variables with 0% of parent scope covered by DW_AT_location
>>>>
>>>> Since I am not very familiar with this code, I would request if you could investigate and apply the patch.
>>>
>>> Hmm, looking at this trying to reproduce the behavior makes me think this wouldn't be the right fix & the change in numbers is probably reflective of a bug in the fix - specifically in LTO situations (where the abstract origin of the function may be in a different CU than the one it's referenced from/inlined into).
>>>
>>> But there might be a reasonable alternative fix/improvement - pruning the contents of the list once it has been handled. Possibly sorting the list so it's easy to just visit the elements that need to.
>>
>> I have taken a look into this and come up with the similar conclusion.
>> This could be reproduced with the Split DWARF -- when building e.g. GDB project with -gsplit-dwarf option enabled, it triggers the issue. I was struggling to make a simple test case (from a high level) that meets all the requirements, but it is very hard. That is why I've sent the email: https://lists.llvm.org/pipermail/llvm-dev/2021-April/149735.html.
>
> Ah, hmm - why would this come up in Split DWARF, do you think? Split DWARF doesn't have any cross-CU references (the format has no way to encode them) so I'd expect no DIEs to be added to the InlinedFnsToBeProcessed list?

The example I had in my mind is a bit different (I haven't looked into cross-cu support yet, but we should have covered it).
Let me first explain two main variables here:

`GlobalInlinedFnInfo` -- keeps track of `DW_TAG_subprogram` copies with `DW_AT_inline`, so when we face a `DW_TAG_inlined_subroutine` we know for how many variables we have zero % location coverage
`InlinedFnsToBeProcessed` -- doing recursive approach if we can firsly meet a `DW_TAG_inlined_subroutine` referencing a  `DW_TAG_subprogram` copy with `DW_AT_inline` (since DWARF standard does not propose the order), this variable keeps the `DW_TAG_inlined_subroutine` DIEs that should be processed after we are finished with the dwarf tree

Let us know consider a big project (let it be GDB) compiled with -gsplit-dwarf. Main executable will have debug_info section:

  $ llvm-dwarfdump gdb
  0x0000000b: DW_TAG_compile_unit
             DW_AT_stmt_list   (0x00000000)
             DW_AT_comp_dir    ("/gdb")
             DW_AT_GNU_pubnames        (true)
             DW_AT_GNU_dwo_name        ("gdb.dwo")
             DW_AT_GNU_dwo_id  (0xb8ed71b1bb823706)
             DW_AT_low_pc      (0x0000000000482370)
             DW_AT_high_pc     (0x000000000048239a)
             DW_AT_GNU_addr_base       (0x00000000)
  0x00000030: Compile Unit: length = 0x00000030, format = DWARF32, version = 0x0004, abbr_offset = 0x001a, addr_size = 0x08 (next unit at 0x00000064)

  0x0000003b: DW_TAG_compile_unit
             DW_AT_stmt_list   (0x00000069)
             DW_AT_comp_dir    ("/gdb")
             DW_AT_GNU_pubnames        (true)
             DW_AT_GNU_dwo_name        ("amd64-tdep.dwo")
             DW_AT_GNU_dwo_id  (0x97c5a9e4ce1a43bf)
             DW_AT_GNU_ranges_base     (0x00000000)
             DW_AT_low_pc      (0x00000000004823a0)
             DW_AT_high_pc     (0x000000000048e982)
             DW_AT_GNU_addr_base       (0x00000018)
  0x00000064: Compile Unit: length = 0x0000002c, format = DWARF32, version = 0x0004, abbr_offset = 0x0037, addr_size = 0x08 (next unit at 0x00000094)

  0x0000006f: DW_TAG_compile_unit
  ....

We will keep filling both of these variables (GlobalInlinedFnInfo and InlinedFnsToBeProcessed) for all the CUs, but there could be a situation where we have inlined_subroutine referencing a subprogram, but we accidently use variables info from subprogram from previous CU with the same DIE offset -- that is why we have different numbers for this case.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D96045/new/

https://reviews.llvm.org/D96045