From: Rishi Dixit <dixit_rishi@acmet.com>
To: Mailing List <gdb@sourceware.org>
Subject: Resume from Breakpoint - Next Instruction Address or Target Address?
Date: Mon, 30 Jan 2006 20:16:00 -0000 [thread overview]
Message-ID: <1138623528.3621.173.camel@rishidixit> (raw)
[-- 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
next reply other threads:[~2006-01-30 12:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-30 20:16 Rishi Dixit [this message]
2006-02-06 23:47 ` Daniel Jacobowitz
2006-02-10 12:05 ` Rishi Dixit
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=1138623528.3621.173.camel@rishidixit \
--to=dixit_rishi@acmet.com \
--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