[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