[Lldb-commits] [PATCH] D62634: Improve DWARF parsing and accessing by 1% to 2%

[Greg Clayton via lldb-commits]

> On Jun 3, 2019, at 8:33 AM, Pavel Labath via Phabricator <reviews at 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
> 
> 
>