public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
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)

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