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

[Pavel Labath via lldb-dev]

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