> On Jan 16, 2015, at 1:12 PM, Zachary Turner <ztur...@google.com> wrote:
>
>
>
> On Fri Jan 16 2015 at 12:45:00 PM <jing...@apple.com> wrote:
>
> > On Jan 16, 2015, at 12:14 PM, Zachary Turner <ztur...@google.com> wrote:
> >
> > I'm still trying to wrap my head around the way LLDB does things.
> >
> > If I understand correctly, when you run thread step-over, it enters single
> > step mode (by setting the trap flag on the CPU). Every time the CPU traps,
> > LLDB picks this up and asks the ThreadPlan "should i stop now?" "should i
> > stop now?" until the ThreadPlan returns true. And part of this "should i
> > stop now" involves generating an unwind.
> >
>
> That's close, but not quite correct.
>
> 1) In the original implementation, (and this is how gdb does it, BTW) lldb
> single-stepped till "something interesting happened." As an optimization,
> when you are doing any kind of step through source range, I changed lldb so
> it runs from "instruction that could branch" to "instruction that could
> branch" using breakpoints. Then when it hits an instruction that could
> branch it single steps that instruction, and then figures out from where that
> went what to do next.
>
> BTW, if it were helpful to figure out what to do next, we could store some
> info (the old stack frame or whatever) when we hit a branch instruction, and
> then use it when the single-step completed. I haven't needed to do that yet,
> however; Jason's always been able to get the unwinder work reliably enough
> not to require this.
> Let's say you're stopped at the first line of foo() here.
>
> 1. void foo()
> 2. {
> 3. -> printf(
> 4. "Line 1\n");
> 5. printf("Line 2\n");
> 6. printf("Line 3\n");
> 7. }
>
> When you step-over, why can't it just say: Ok, current source line is 3.
> Debug info tells me that the next instruction begins on line 5. Line 5
> corresponds to address 0x12345678. Put a breakpoint on 0x12345678. To
> account for the fact that foo() may be recursive, also save off a copy of the
> stack pointer. When the breakpoint is hit, stop if the stack pointer is the
> same or less than the saved value (depending on the definition of "less" for
> your architecture), otherwise don't stop.
That would be easy if you knew the current source line had no internal
branches, but debug information doesn't have semantic information, only address
range information.
Suppose the line current line is:
if (foo == 7) goto someLabel;
How do you know where that is going to go from source range information? You
could pre-scan the line for branches and if the target is static you could
figure out where they are going to go and set breakpoints on all the targets.
Then of course in some languages you even have computed goto's, so you would
actually have to do a full emulation of the instruction range to know what is
going to happen. At which point just watching the instructions as they go past
is more accurate.
Jim
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
