> On Jun 3, 2019, at 8:33 AM, Pavel Labath via Phabricator
> <revi...@reviews.llvm.org> wrote:
>
> labath added a subscriber: dblaikie.
> labath added a comment.
>
> Actually, there was a subtle change of behavior here. Before this change, if
> we tried to parse a DIE using an abbreviation table from a different file, we
> would most likely fail immediately because of the fail-safe in
> GetAbbreviationDeclarationPtr. Now, we just do a blind read and return bogus
> data.
This seems just like a straight up bug we need to fix in LLDB. It shouldn't
affect or require any changes from any compilers. Seems like a lldbassert that
maybe verifies that the abbreviation we use is valid for the current CU in
debug builds would be nice so we can trigger this bug when we run the test
suite or locally against an example program would be good. Depending on that
fact that we have a mismatch in the abbrev index seems fragile. Most
.debug_abbrev tables start out with a DW_TAG_compile_unit. So if the abbrev
index magically matches, that still doesn't mean the we will be decoding the
right data even if the index matches.
>
> Now, normally this shouldn't matter, but in case of split-dwarf, things start
> to get interesting. Lldb has this assumption that when we are reading a debug
> info entry (which is not the CU DIE), we are actually reading it from the dwo
> compile unit and not the skeleton unit in the main file. This means it uses
> the dwo abbreviation list and everything. Now, as far as I can tell, LLDB is
> kind of right here. The DWARF5 (in v4 split dwarf was a non-standard
> extension) spec says "A skeleton compilation unit has no children." (3.1.2
> Skeleton Compilation Unit Entries). And indeed, gcc produces compilation
> units with no children. Clang, on the other hand, seems to be putting some
> DIEs into the main CU, **if** the compilation results in functions being
> inlined. And it seems clang has been doing this since at least 7.0 (I
> haven't tried older versions).
>
> So it seems we have two problems here:
>
> 1. We need to figure out whether there's a bug in clang and fix it. +
> @dblaikie for help with that
> 2. Depending on the outcome of the first item, we need to do something in
> lldb to handle this. If this is a clang bug (and my feeling is that it is),
> then the best solution might be to just start ignoring any non-CU dies from
> the main file in split-dwarf scenario
>
> @dblaikie: Do you agree with my assessment above? If this is indeed a clang
> bug, any chance you could help with debugging the clang/llvm side of things?
>
> The simplest reproducer for this would be something like:
>
> inline __attribute__((always_inline)) int foo(int x) { return x; }
>
> int main(int argc) { return foo(argc); }
>
> `$ clang++ a.cc -c -o a.o -g -gsplit-dwarf`
I don't believe we need to fix or change anything in the compiler since this is
just a bug in LLDB. If LLDB was relying on incorrect behavior before that is
bad, but we should just fix the issues in LLDB.
Greg
>
> CHANGES SINCE LAST ACTION
> https://reviews.llvm.org/D62634/new/
>
> https://reviews.llvm.org/D62634
>
>
>
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
