Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <cagney@gnu.org>
To: Orjan Friberg <orjan.friberg@axis.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: STEP_SKIPS_DELAY question, sort of
Date: Mon, 24 May 2004 18:15:00 -0000	[thread overview]
Message-ID: <40B23BB2.6070001@gnu.org> (raw)
In-Reply-To: <40B1BD1B.4090300@axis.com>

Andrew Cagney wrote:

Earlier MIPS variants (at least) needed STEP_SKIPS_DELAY.  When at ``0x0'', a hardware single-step would end up at ``foo''.  That isn't your problem.

Since your hardware can single-step into a delay slot, can it also resume from the delay slot?  An example of this is SPARC with its constantly shuffling PC/N[ext]PC -- the inferior is resumed with PC==0x2 N[ext]PC==foo.


I'm not sure I understand what you mean by "can resume" - it can resume from a delay slot, but when doing so the branch instruction (and the delay slot) is re-executed.  I don't have an NPC, and AFAIK there's no information in the CPU registers that tells me whether the branch is taken or not (which seems consistent with the fact that the branch-instruction is re-executed).
Ok, I'm starting to understand the wierdness

The SPARC (using PC/NextPC) resumes from the delay slot so re-inserting 
the breakpoint is safe - that branch instruction is never re-executed. 
Your architecture isn't like this.



I think there is still some missing information.  Given:
  N+0: branch foo
  N+2: nop
and PC==N+0, exactly what state information is available after doing a 
single hardware single-step (PC and status registers)?

- If I understand things correctly, one h/w single-step gets PC==N+2 and 
two h/w single-steps gets PC==foo.  For that to work there must be some 
additional state information lurking somewhere - a bit indicating 
stopped in delay slot perhaphs?

- If there were a breakpoint at N+2, what state information would be 
available then.  If the breakpoint were then yanked, where would a 
single-step end up - again additional state information is needed to 
make this work?

Maybe this can be stated in even simpler terms than "don't re-insert a breakpoint on an instruction that's going to be restarted when we resume execution".  Rather, "single-step twice before re-inserting a breakpoint we're currently stopped at". 
GDB needs to know that its in such a state.

Andrew




  reply	other threads:[~2004-05-24 18:15 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-21 17:14 Orjan Friberg
2004-05-21 20:25 ` Andrew Cagney
2004-05-24  9:15   ` Orjan Friberg
2004-05-24 18:15     ` Andrew Cagney [this message]
2004-05-25 11:53       ` Orjan Friberg
2004-05-25 21:14         ` Andrew Cagney
2004-05-26  9:39           ` Orjan Friberg
2004-05-26 17:39             ` Andrew Cagney
2004-06-07 12:12             ` Orjan Friberg
2004-06-07 12:42               ` Orjan Friberg
2004-06-07 13:09                 ` Orjan Friberg
2004-06-07 15:08                   ` Andrew Cagney
2004-06-09  9:48                     ` Orjan Friberg
2004-06-09 16:00                       ` Andrew Cagney
2004-06-14 12:09                         ` Orjan Friberg
2004-06-16 14:53                           ` Orjan Friberg
2004-06-24 18:25                             ` Andrew Cagney
2004-10-01 11:26                         ` Orjan Friberg
2004-10-25 20:18                           ` Andrew Cagney

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=40B23BB2.6070001@gnu.org \
    --to=cagney@gnu.org \
    --cc=gdb-patches@sources.redhat.com \
    --cc=orjan.friberg@axis.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