Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Rishi Dixit <dixit_rishi@acmet.com>
To: Daniel Jacobowitz <drow@false.org>
Cc: Mailing List <gdb@sourceware.org>
Subject: Re: Resume from Breakpoint - Next Instruction Address or Target 	Address?
Date: Fri, 10 Feb 2006 12:05:00 -0000	[thread overview]
Message-ID: <1139573166.3619.0.camel@rishidixit> (raw)
In-Reply-To: <20060206234711.GA523@nevyn.them.org>

On Tue, 2006-02-07 at 05:17, Daniel Jacobowitz wrote: 
> On Mon, Jan 30, 2006 at 05:48:48PM +0530, Rishi Dixit wrote:
> > Hi,
> > 
> > 
> > I am studying about breakpoint functionality in GDB. My study is local
> > to the MIPS Simulator. While studying the GDB source, I was referring
> > the handling of BREAK instruction. 
> > 
> > This handling checks for the presence of BREAK instruction in a delay
> > slot and alters the Program Counter. However, this information is
> > overwritten when the CPU registers are saved before triggering a
> > Breakpoint exception. 
> > 
> > I suspected this would lead to a loss of information regarding the
> > target address of jump/branch instruction. To confirm this, I made a
> > test case and checked the GDB behavior. 
> 
> I don't know - you'd have to ask someone more familiar with the
> architecture and the simulator - but I think this is a bug in either
> the simulator or GDB; the architecture does provide enough information
> to handle this case.  See the documentation of the BD bit in the Cause
> register.

I tried some modifications based on this information in the
documentation. These were done before the handling of the Breakpoint
Exception, which is raised whenever a Breakpoint is hit. However, if the
value of Program Counter is altered then the handling of breakpoints in
GDB is disturbed. 

Another angle is that this can be checked for when the simulator is
resuming after the exception has been serviced. When this is being done,
the program counter can be altered based on the information of the BD
bit in Cause register.

> > My assumption is that since the breakpoint is hit after the jump/branch
> > instruction has been executed, the resume should be from the target
> > address. 
> 
> No, generally we want to resume where we were, not where we're going
> to.  The resume should be back on the jump.  I have no idea if GDB
> implements that.

Thanks for clearing my doubt. The resume should be from the preceding
branch/jump instruction. After this instruction is processed, the
control jumps to the target address.


      reply	other threads:[~2006-02-10 12:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-30 20:16 Rishi Dixit
2006-02-06 23:47 ` Daniel Jacobowitz
2006-02-10 12:05   ` Rishi Dixit [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=1139573166.3619.0.camel@rishidixit \
    --to=dixit_rishi@acmet.com \
    --cc=drow@false.org \
    --cc=gdb@sourceware.org \
    /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