Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Simon Marchi <simon.marchi@ericsson.com>,
	Yao Qi <qiyaoltc@gmail.com>,
	       gdb-patches@sourceware.org
Subject: Re: Move threads out of jumppad without single step
Date: Mon, 30 Nov 2015 19:39:00 -0000	[thread overview]
Message-ID: <565CA5DC.9030009@redhat.com> (raw)
In-Reply-To: <565C9DA8.4010605@ericsson.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 [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


  reply	other threads:[~2015-11-30 19:39 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-27 10:55 Yao Qi
2015-11-30 14:42 ` Pedro Alves
2015-11-30 19:04   ` Simon Marchi
2015-11-30 19:39     ` Pedro Alves [this message]
2015-12-01 11:36   ` Yao Qi
2016-01-27 16:47     ` Antoine Tremblay
2016-01-29 20:43       ` Antoine Tremblay
2016-02-04 16:58         ` Yao Qi
2016-02-04 18:24           ` Antoine Tremblay

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=565CA5DC.9030009@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=qiyaoltc@gmail.com \
    --cc=simon.marchi@ericsson.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox