Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <cagney@gnu.org>
To: gdb-patches@sources.redhat.com
Cc: Daniel Jacobowitz <drow@false.org>
Subject: Re: [patch/rfc] Rewrite decr-pc logic, eliminate step_sp
Date: Wed, 12 May 2004 18:04:00 -0000	[thread overview]
Message-ID: <40A26731.8010407@gnu.org> (raw)
In-Reply-To: <409FD475.50003@gnu.org>

+  if (currently_stepping (ecs))
+    {
+      if (SOFTWARE_SINGLE_STEP_P ())
+    {
+      if (singlestep_breakpoints_inserted_p
+          && prev_pc == breakpoint_pc)
+        /* If we're software-single-stepping, assume we hit one of
+           the inserted software breakpoints.  */
+        write_pc_pid (breakpoint_pc, ecs->ptid);
+    }


I'm pretty sure that won't work.  prev_pc is where we were stopped
before we decided to single step.  breakpoint_pc is where, if we have
hit a breakpoint, the breakpoint would be.  They won't be equal;
breakpoint_pc will be the following instruction, or the target of a
branch if *prev_pc was a taken branch.  The old code assumes we hit a
breakpoint if we stopped with SIGTRAP with singlestep_breakpoints_inserted_p
- any reason not to keep that behavior?


It's plain wrong.  I'm pretty sure that, when doing the thread-hop, singlestep_breakpoints_inserted_p holds, but current_stepping() doesn't.

I think Alpha OSF/1 and Alpha NetBSD are the only current
software-single-step and decr-pc targets, which makes this case a
little hard to test - at least OSF/1 had dreadful test results already,
I'm not sure about NetBSD.  Might want to verify that it isn't
catastrophic, at least.
The rest of it looks right to me, though I had to stare at it for
the last twenty minutes or so.


I gave up staring at the old code, it made no sense.

Attached is a revision.
I've checked this in.  In addition to PPC (h/w single step) and i386 
(decr pc after break) I gave it a sniff test on alpha GNU/Linux (hacked 
to use s/w single step).

Andrew

2004-05-09  Andrew Cagney  <cagney@redhat.com>

	* infrun.c (adjust_pc_after_break): Rewrite decr logic,
	eliminate reference to step_sp.
	(struct execution_control_state, init_execution_control_state)
	(handle_inferior_event, keep_going): Delete update_step_sp and
	step_sp.
	* infcmd.c (step_sp): Note that variable is unused.




      reply	other threads:[~2004-05-12 18:04 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-10  4:01 Andrew Cagney
     [not found] ` <20040510043222.GA30284@nevyn.them.org>
2004-05-10 19:14   ` Andrew Cagney
2004-05-12 18:04     ` Andrew Cagney [this message]

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=40A26731.8010407@gnu.org \
    --to=cagney@gnu.org \
    --cc=drow@false.org \
    --cc=gdb-patches@sources.redhat.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