[Lldb-commits] [PATCH] D96778: [lldb] Fix handling of `DW_AT_decl_file` according to D91014

David Blaikie via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Thu Feb 18 14:13:57 PST 2021


dblaikie added a comment.

In D96778#2572405 <https://reviews.llvm.org/D96778#2572405>, @jankratochvil wrote:

> In D96778#2566208 <https://reviews.llvm.org/D96778#2566208>, @dblaikie wrote:
>
>> I expect it'd be good to have a test case showing the sort of DWARF that DWZ produces for cross-CU references of enumerators.
>
> Here is a new testcase for the second (`DW_TAG_variable`) fix: https://people.redhat.com/jkratoch/D96778-test.patch
> I cannot update the patch here.

Ah, cool - for the final version of this, I'd suggest the author/whomever rolls this into one file with two CUs - bit easier to deal with. You could remove a bunch of extraneous DWARF too - since it's hardcoded DWARF, the subprogram/inlined subroutine/etc could be removed from CU1, leaving only the abstract subprogram and variable, both to be referenced from CU2.

> DWZ can produce such case from GCC output (not used for the testcase): `g++ -o inlinevar inlinevar{1,2}.C -Wall -g -O2;dwz ./inlinevar`
> Such case is never produced clang output as the `DW_TAG_variable declaration` is not merged by `clang -flto` and DWZ for unknown reason does not merge the clang variant. I did merge it for the testcase from clang output by hand.
>
> I did not try a testcase for the enumerators if possible at all.

Could you provide the source code for this - I wouldn't mind trying it out and seeing what might be different/why DWZ doesn't understand this.

The LTO point you make is an interesting one too... yeah, for non-inlined (but inline linkage) functions LLVM during LTO deduplicates correctly, but this doesn't work out once inlining happens.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96778



More information about the lldb-commits mailing list