BTW, Zachary's question here was not a dumb one. A full stack backtrace is not cheap, so when hacking on lldb, never ask for more frames than you need. It isn't as expensive as it was in gdb since we separate unwinding the pc/cfa from unwinding the arguments up the stack, but still, a full stack trace should only get done in response to some high level user request.
Jim > On Jan 20, 2015, at 1:16 PM, Jason Molenda <ja...@molenda.com> wrote: > > >> On Jan 20, 2015, at 1:06 PM, jing...@apple.com wrote: >> >> >>> On Jan 20, 2015, at 12:31 PM, Zachary Turner <ztur...@google.com> wrote: >>> >>> In practice how slow is this for stepping over very lengthy calls? It >>> sounds like LLDB still generates a call stack at every branch point, which >>> while certainly faster than generating one at every instruction, still >>> seems like it has the potential to be very slow. >> >> At most, lldb only needs to get the current frame & its parent frame to run >> its stepping algorithm. It won't generate a full stack frame unless you ask >> it to. Getting two frames should be pretty quick. > > Specifically -- it will take three packets. The initial stop packet gives us > enough registers to know what the current stack frame is. lldb will make one > memory read of the stack memory, which gives it enough to reconstruct the > caller stack frame. T packet, memory read, memory read result. Then lldb > knows whether to continue stepping, set a breakpoint & resume, or stop > stepping. _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
