Resume from Breakpoint - Next Instruction Address or Target Address?

Resume from Breakpoint - Next Instruction Address or Target Address?

[Rishi Dixit]

[-- Attachment #1: Type: text/plain, Size: 1674 bytes --]

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. 

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. 

However, it occurred that the GDB resumes from the instruction
next to the breakpoint location, which in this case will be the
instruction present next to the delay slot instruction.

Studying the code, I found that the Program Counter must contain the
current instruction address in order to ensure normal processing of
breakpoints. If this is altered, the breakpoint functionality in GDB
gets affected.

However, this seems contrary to my assumption that the resume should be
from the target address instead of the next instruction address. Is this
assumption correct?

Furthermore, I wasn't able to pinpoint any part of the code where the
lost information about target address could be restored after the
breakpoint has been handled. 

Please check my understanding. If the above described condition can be
handled, please provide me with pointers in the source.

The prepared test case is attached.


Thanks in advance,
Rishi Dixit

[-- Attachment #2: delayslotbreak.s --]
[-- Type: text/plain, Size: 414 bytes --]

	.file	1 "delayslotbreak.c"
	.text
	.align	2
	.globl	main
	.globl  stop
	.ent	main
main:
	.frame	$fp,8,$31		# vars= 0, regs= 1/0, args= 0, gp= 0
	.mask	0x40000000,-8
	.fmask	0x00000000,0
        j       _target
stop:					# Execution is stopped here
        nop				# This is the delay slot instruction
        lw      $2,0
_target:				# Execution should resume from here            
	j	$31
	.end	main

	.comm	i,4,4

Re: Resume from Breakpoint - Next Instruction Address or Target Address?

[Daniel Jacobowitz]

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.

> 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.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Resume from Breakpoint - Next Instruction Address or Target Address?

[Rishi Dixit]

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.