This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: RFC : Handling breakpoints on archs. with imprecise exceptions.
- From: Ramana Radhakrishnan <ramana dot radhakrishnan at codito dot com>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: gdb at sources dot redhat dot com, amit bhor <amit dot bhor at codito dot com>
- Date: Fri, 25 Mar 2005 04:16:11 +0530
- Subject: Re: RFC : Handling breakpoints on archs. with imprecise exceptions.
- References: <42431904.7010708@codito.com> <20050324203814.GA7529@nevyn.them.org>
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.
It sounds plausible, although messy. Does a single-instruction
branch always give you enough range to reach a breakpoint table?
At the moment yes, since the branch would give a 16MB range
per app. The case is for uClinux apps on the ARC600
platform. ( though one could possibly dream up a solution
that cascaded branches maybe if the footprint so demanded
this sic :-) or KevinB's suggestion later on in the thread . )
I suspect you could handle this by wrapping gdbarch_read_pc, so that
a "breakpoint" at a particular "pc" would appear to stop there rather
than in the table. Be sure to restore the correct pc at that point.
This is where one does the reverse mapping.
That and breakpoint_from_pc may be all the hooks you need. And maybe
hooks in target_insert_breakpoint/target_remove_breakpoint to reference
count.
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.
You should be hooking insert/remove breakpoint, not add/delete user
breakpoint.
Aha! that would be because for one, breakpoints for single
stepping need not necessarily be in the breakpoint table .
Does gdbarch_read_pc do everything you need for the wait_hook? You can
update the PC from there if necessary.
Sounds equivalent, though not yet sure. Will give it a shot
in the next couple of days and post the results.
cheers
Ramana
--
Ramana Radhakrishnan
GNU Tools
codito ergo sum (www.codito.com)