[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
Sat Feb 20 11:44:47 PST 2021


dblaikie added a comment.

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

> In D96778#2572816 <https://reviews.llvm.org/D96778#2572816>, @dblaikie wrote:
>
>> rolls this into one file with two CUs - bit easier to deal with.
>
> Then one could not use the `.file` directives and one would need to code also `.debug_line` by hand.

Ah, right, makes sense.

>> 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.
>
> dwz will merge it without -flto but not with -flto: http://people.redhat.com/jkratoch/inlinevar.d.tar.xz

Ah, yeah, so I see - thanks for the repro!

If I had to guess, it'd be because with LTO clang emits the abstract origin lexically after the inlined instance of "var", whereas with non-LTO clang emits the abstract origin before the inlined instance.

(& yeah, clang should get this right with lto without the need for dwz - LLVM correctly deduplicates types when merging for LTO, but doesn't do so for already-inlined functions, could be done with the same sort of logic, though)

> Personally I am not interested in DWZ, I am implementing it only as a compatibility with existing file format, IMNSHO DWZ should be dropped.

Not sure I follow. dwz does use the existing DWARF file format. you mean you're only interested in compatibility with the DWARF directly produced by compilers, not post-processed by dwz? Fair enough. I guess @werat has some interest in supporting dwz for their use cases.


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