From: Ramana Radhakrishnan <ramana.radhakrishnan@codito.com>
To: gdb@sources.redhat.com
Cc: Daniel Jacobowitz <drow@false.org>, amit bhor <amit.bhor@codito.com>
Subject: RFC : Handling breakpoints on archs. with imprecise exceptions.
Date: Thu, 24 Mar 2005 19:46:00 -0000 [thread overview]
Message-ID: <42431904.7010708@codito.com> (raw)
Hi,
While looking at a GDB port to a processor that has
imprecise exceptions/ interrupts i.e. the equivalent of a
software breakpoint would require 4 instructions to stop.
With my research I was unable to find any GDB port that
needed to handle such a case.
The mechanism that is in mind is the following for setting
breakpoints.
Description
------------
Maintain a separate breakpoint table to which control would
branch to from the debuggee. So gdb's breakpoint instruction
is replaced by a branch to the corresponding breakpoint
table for the
1 . Replace the instruction with a branch to an entry in a
breakpoint table which already contains the necessary
instructions for this purpose. So all that
breakpoint_from_pc does is to encode this branch instruction
and return this as the breakpoint instruction.
2. The breakpoint once hit gets informed to gdb as a
breakpoint being hit at some location in the breakpoint
table. So when GDB checks for a breakpoint as having been
hit the PC it should use should be the value of the PC at
which the breakpoint was actually set.
GDB specifics.:
---------------
a. Define gdbarch_adjust_breakpoint_address in the backend
to store the mapping in the backend for the PC at which
breakpoint has been set to the actual value for the PC where
the breakpoint would be reported to have been hit.
b. Define deprecated_target_wait_hook in the backend to
restore the actual value of the PC for GDB to continue with
its work.However as this is a deprecated hook I would not
like to use this in a new port.
c. Add a new notify_backend_breakpoint_deleted_hook since
the backend needs notification for the breakpoint being
deleted and hence free an entry in the breakpoint table.
cheers
Ramana
--
Ramana Radhakrishnan
GNU Tools
codito ergo sum (www.codito.com)
next reply other threads:[~2005-03-24 19:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-24 19:46 Ramana Radhakrishnan [this message]
2005-03-24 19:57 ` Paul Gilliam
2005-03-24 20:23 ` Ramana Radhakrishnan
2005-03-24 21:46 ` Paul Gilliam
2005-03-24 20:37 ` Daniel Jacobowitz
2005-03-24 22:46 ` Ramana Radhakrishnan
2005-03-24 21:30 ` Kevin Buettner
2005-03-24 23:31 Decker, Paul
2005-03-24 23:32 ` Daniel Jacobowitz
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=42431904.7010708@codito.com \
--to=ramana.radhakrishnan@codito.com \
--cc=amit.bhor@codito.com \
--cc=drow@false.org \
--cc=gdb@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).