[lldb-dev] Resolving dynamic type based on RTTI fails in case of type names inequality in DWARF and mangled symbols

[Greg Clayton via lldb-dev]

> On Dec 21, 2017, at 8:23 AM, Pavel Labath <labath at google.com> wrote:
> 
> On 21 December 2017 at 10:45, Pavel Labath <labath at google.com> wrote:
>> I'm not sure now whether you're suggesting to use the dsymutil
>> approach just to gauge the potential speedup we can obtain and get
>> people interested, or as a productized solution. If it's the first one
>> then I fully agree with you. Although I think I can see an even
>> simpler way to estimate the speedup: build lldb for mac with apple
>> indexes disabled and compare its performance to a vanilla one. I'm
>> going to see if I can get some numbers on this today.
> 
> 
> Here's some data I gathered today. What I did was I disabled apple
> accelerator table parsing in ObjectFileELF (patch is in the
> attachment) and then I compared startup time when debugging lldb with
> itself. Specifically I used an Release (optimized) lldb to open a
> Debug lldb, set a breakpoint, hit it, display local variables and
> backtrace. The precise command is:
> $ time opt/bin/lldb -o "br set -n DoExecute" -o "pr la" -o "bt" -o "fr
> var" -b -- dbg/bin/lldb -- /bin/ls
> I ran the command three times and chose the median result.
> 
> Before I show the measurements I have to give one big disclaimer: The
> debugger with accelerator tables disabled does not appear to be fully
> functional. Specifically most (all?) of the objc tests in the test
> suite hang, and also 50 additional tests fail (the failures seem to be
> related to expression evaluation, mostly). However, I think the fact
> that the remaining ~2000 tests passed means that we still have been
> reading the dwarf parsing functionality is reasonably intact.
> 
> Now, the numbers:
> vanilla dSYM
> real 0m7.774s
> user 0m15.261s
> sys 0m1.228s
> 
> 
> =====
> vanilla no-dSYM
> real 0m5.987s
> user 0m4.919s
> sys 0m0.698s
> 
> 
> 
> =====
> no-apple dSYM
> real 0m7.616s
> user 0m14.812s
> sys 0m1.208s
> 
> 
> =====
> no-apple no-dSYM
> real 0m45.520s
> user 0m31.096s
> sys 0m11.101s
> 
> 
> 
> It's not fully clear to me how to interpret this data. The difference
> between having the accelerator tables and not is approximately what I
> would expect (a lot) in the no-dSYM scenario, and I believe this is
> the kind of speedup we should expect on linux. However, there are also
> some question marks, like why is the time virtually unchanged in case
> we have a dSYM bundle around? Also, the difference between having dSYM
> and not is quite large (and opposite to what I would expect) in
> "vanilla" case.
> <apple.diff>

So results might be wrong because you can't debug /bin/ls and many commands might just not be happening (as soon as you get an error, the command stop happening). /bin/ls is Apple signed and SIP (system integrity protection) will stop you from actually debugging it. Did you disable SIP?