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 <clayb...@gmail.com> wrote: > >> On Dec 21, 2017, at 8:23 AM, Pavel Labath <lab...@google.com> wrote: >> >> On 21 December 2017 at 10:45, Pavel Labath <lab...@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? > _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
