[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]

I wonder if making indexing multi-threaded has solved speed issues?

> On Dec 21, 2017, at 8:54 AM, Pavel Labath <labath at google.com> wrote:
> 
> That's not the case, the nested debugger get's stopped in
> CommandObjectTargetCreate::DoExecute before it even touches the
> /bin/ls file. I could have passed anything there (probably /bin/ls
> wasn't the best choice though), it's just this was the easiest thing I
> came up with for stopping at a place with a non-trivial backtrace and
> local variables.
> 
> I've verified that in each test scenario the (outer) debugger prints
> out a reasonable backtrace and local variable values.
> 
> 
> 
> On 21 December 2017 at 16:46, Greg Clayton <clayborg at gmail.com> wrote:
>> 
>>> 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?
>>