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

Mon Jun 3 17:36:30 PDT 2019

dblaikie added a comment.

In D62634#1527634 <https://reviews.llvm.org/D62634#1527634>, @probinson wrote:

> In D62634#1527575 <https://reviews.llvm.org/D62634#1527575>, @dblaikie wrote:
>
> > 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.
>
>
> I think we have to tolerate the msan part.  However, the profile feedback workflow could (should) surely be taught to read a .dwo file.  The point of -fdebug-info-for-profiling was so you don't have to emit limited/full debug info in the .o file just to make profiling work; but if you're using split DWARF then you're doing limited/full anyway, and the feedback loop happens in the context of a build environment so the .dwo can be asserted to be available.  So in split DWARF mode, we should not be emitting debug-info-for-profiling into the skeleton.

Ah, hmm, looks like debug-info-for-profiling+split+-dwarf-inling ends up in a slighty hybrid state. DIFP does add the linkage name, decl line and decl file to subprograms, beyond just the simple name that gmlt would normally provide. But one of DIFP's other features doesn't trigger on the split-dwarf-inlining: it doesn't cause descriptions of functions without any inlining to be described.

>> Chances are it's probably best for a debugger to ignore these entries.
> 
> This stuff is going to show up in the wild, so yeah.  You know you're looking at a skeleton, so don't bother looking at any children.

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

https://reviews.llvm.org/D62634