Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Yao Qi <qiyaoltc@gmail.com>, gdb-patches@sourceware.org
Subject: Re: [RFC] Remove need_step_over from struct lwp_info
Date: Thu, 28 Apr 2016 10:10:00 -0000	[thread overview]
Message-ID: <89e60caa-7324-5bca-2cfa-ece25b46e7c3@redhat.com> (raw)
In-Reply-To: <1461657497-12076-1-git-send-email-yao.qi@linaro.org>

On 04/26/2016 08:58 AM, Yao Qi wrote:
> Hi,
> I happen to see that field need_step_over in struct lwp_info is only
> used to print a debug info.  need_step_over is set in linux_wait_1
> when breakpoint_here is true, however, we check breakpoint_here too in
> need_step_over_p and do the step over.  I think we don't need field
> need_step_over, and check breakpoint_here directly in need_step_over_p.
> 
> This field was added in this patch
> https://sourceware.org/ml/gdb-patches/2010-03/msg00605.html and the code
> wasn't changed much since then.
> 
> This patch is to remove it.
> 

The intention was for this:

  if (!lwp->need_step_over)
    {
      if (debug_threads)
	debug_printf ("Need step over [LWP %ld]? No\n", lwpid_of (thread));
    }

to not just be a debug print, but also a return.  Looks like
that might have been only on an earlier prototype, or I messed
it up and removed the return by accident before posting or
some such.


This is why we have comments like:

      if (bp_explains_trap)
	{
	  /* If we stepped or ran into an internal breakpoint, we've
	     already handled it.  So next time we resume (from this
	     PC), we should step over it.  */
	  if (debug_threads)
	    debug_printf ("Hit a gdbserver breakpoint.\n");

	  if (breakpoint_here (event_child->stop_pc))
	    event_child->need_step_over = 1;


The idea was that if the thread happens to be stopped
at a breakpoint, but the breakpoint wasn't actually hit yet, you'd
want to let it be hit, rather than step over it.  E.g., say you have
2 threads, and thread 1 stops for a breakpoint at PC1.  Since we're
in all-stop mode, gdbserver pauses thread 2 as well.  Thread 2 pauses
at PC2.  Now the user sets a breakpoint at PC2.  User continues.
gdbserver at that time would step over the breakpoint at PC2, which
is not what GDB expects.  Likewise, if the user starts a trace session
with a tracepoint at PC2, while thread 2 is stopped at PC2, gdbserver
would skip the tracepoint rather than collect it immediately.

However, since:

 [x86-linux Z0 support, and support multiple breakpoints at the same address]
 https://sourceware.org/ml/gdb-patches/2010-03/msg00917.html

need_step_over_p checks gdb_breakpoint_here, so unless the target doesn't
support Z0 breakpoints, the gdb breakpoint case ends up handled that way.
And the tracepoint case is probably not a big deal, and we can live with
it.

In any case, looks like this never worked upstream, so I'm super
fine with removing the field and cleaning this all up.

Thanks,
Pedro Alves


  parent reply	other threads:[~2016-04-28 10:10 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-26  7:58 Yao Qi
2016-04-28  9:23 ` Yao Qi
2016-04-28 10:10 ` Pedro Alves [this message]
2016-04-28 10:55   ` Yao Qi

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=89e60caa-7324-5bca-2cfa-ece25b46e7c3@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=qiyaoltc@gmail.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