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

[David Blaikie via Phabricator via lldb-commits]

dblaikie added a comment.

In D62634#1527533 <https://reviews.llvm.org/D62634#1527533>, @labath wrote:

> 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.
>
> 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


This is intentional behavior in clang (controllable under the -f[no-]split-dwarf-inlining flag, and modified by the -f[no-]debug-info-for-profiling flag).

This extra debug info is used for online symbolication (in the absence of .dwo files) - such as for the sanitizers (accurate symbolication is necessary for correctness in msan, due to msan's necessary use of blacklisting to avoid certain false positives) and some forms of sample based profiling collection.

In the default mode, clang includes, as you noted, just the subprograms that have inlined subroutines in them in this split-dwarf-inlining data.
In -fdebug-info-for-profiling all subprograms are described in the skeleton CU with some minimal attributes (they don't need parameters, local variables/scopes, etc) necessary to do certain profile things I don't know lots about.

Chances are it's probably best for a debugger to ignore these entries.

> 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`




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

https://reviews.llvm.org/D62634