This is the mail archive of the
mailing list for the GDB project.
Re: Move threads out of jumppad without single step
- From: Pedro Alves <palves at redhat dot com>
- To: Simon Marchi <simon dot marchi at ericsson dot com>, Yao Qi <qiyaoltc at gmail dot com>, gdb-patches at sourceware dot org
- Date: Mon, 30 Nov 2015 19:39:08 +0000
- Subject: Re: Move threads out of jumppad without single step
- Authentication-results: sourceware.org; auth=none
- References: <86zixzvhj1 dot fsf at gmail dot com> <565C6043 dot 4040106 at redhat dot com> <565C9DA8 dot 4010605 at ericsson dot com>
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  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.
> 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,
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