This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Move threads out of jumppad without single step


On 11/30/2015 07:04 PM, Simon Marchi wrote:
> On 15-11-30 09:42 AM, Pedro Alves wrote:
>> So I assume it's much simpler to just run to [1] as well, and then issue
>> a normal software single-step when you get there.
>>
>> Also, not sure, but it's possible the stabilize threads machinery may
>> need work to handle the "wrong threads" hitting that "out of jump pad"
>> single-step breakpoint for another thread, and not have them start
>> a new start over, but instead have them be locked immediately.
> 
> To be clear, do you mean, when single stepping the last jump pad instruction,
> the jump that goes back to the regular code?  When putting a breakpoint on the
> next pc of that instruction, it means putting a breakpoint in the regular code.

Right.

> 
> However, when doing a single step in gdbserver, aren't all other threads stopped?
> 

That's really a function of whether we're stepping over a breakpoint; in that case
we must stop all threads, but that's true when you step past a breakpoint with
either software single-step or hardware single-step.   IOW, it's an orthogonal,
though tangent issue.   E.g., when software single stepping for a tracepoint's
while-stepping action, I don't see why you'd stop all threads.

In this case, if the thread reached the breakpoint set at the last instruction of
the jump pad, we don't need that breakpoint anymore.  So for the last single-step
we can compute the next PC, install a breakpoint there, and continue, no
need to start a step-over process (pause all threads, remove bp, step, reinsert bp,
unpause all).

On the other hand, always leaving that breakpoint inserted while the stabilization
is in progress and then making that final single-step be a step-over operation
could make things simpler.  Or not, not sure.  We currently track the breakpoint's
lifetime by putting it in the lwp structure (lwp->exit_jump_pad_bkpt), because
it's per-lwp.  If we keep it inserted, then we need to track its lifetime
differently.

Thanks,
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]