* RFC : Handling breakpoints on archs. with imprecise exceptions.
@ 2005-03-24 19:46 Ramana Radhakrishnan
2005-03-24 19:57 ` Paul Gilliam
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Ramana Radhakrishnan @ 2005-03-24 19:46 UTC (permalink / raw)
To: gdb; +Cc: Daniel Jacobowitz, amit bhor
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)
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: RFC : Handling breakpoints on archs. with imprecise exceptions.
2005-03-24 19:46 RFC : Handling breakpoints on archs. with imprecise exceptions Ramana Radhakrishnan
@ 2005-03-24 19:57 ` Paul Gilliam
2005-03-24 20:23 ` Ramana Radhakrishnan
2005-03-24 20:37 ` Daniel Jacobowitz
2005-03-24 21:30 ` Kevin Buettner
2 siblings, 1 reply; 9+ messages in thread
From: Paul Gilliam @ 2005-03-24 19:57 UTC (permalink / raw)
To: gdb; +Cc: Ramana Radhakrishnan, Daniel Jacobowitz, amit bhor
Isn't this usually handled by the kernel?
On Thursday 24 March 2005 11:46, Ramana Radhakrishnan wrote:
> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: RFC : Handling breakpoints on archs. with imprecise exceptions.
2005-03-24 19:57 ` Paul Gilliam
@ 2005-03-24 20:23 ` Ramana Radhakrishnan
2005-03-24 21:46 ` Paul Gilliam
0 siblings, 1 reply; 9+ messages in thread
From: Ramana Radhakrishnan @ 2005-03-24 20:23 UTC (permalink / raw)
To: pgilliam; +Cc: gdb, Daniel Jacobowitz, amit bhor
Hi,
> Isn't this usually handled by the kernel?
How could this be handled by the kernel ? The point is that
one needs to insert 4 instructions in the place of one for a
software breakpoint and the mechanism mentioned in my
earlier mail is possibly one of the methods . (The point is
one cannot ignore the next 3 instructions in the pipeline
since one of them could be a branch to some location , so a
simple DECR_PC_AFTER_BREAK would not necessarily work always )
Addr to set breakpoint: someinsn
b bar
Having said that, could you point me to any kernel that does
this ?
cheers
Ramana
--
Ramana Radhakrishnan
GNU Tools
codito ergo sum (www.codito.com)
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: RFC : Handling breakpoints on archs. with imprecise exceptions.
2005-03-24 20:23 ` Ramana Radhakrishnan
@ 2005-03-24 21:46 ` Paul Gilliam
0 siblings, 0 replies; 9+ messages in thread
From: Paul Gilliam @ 2005-03-24 21:46 UTC (permalink / raw)
To: Ramana Radhakrishnan; +Cc: gdb, Daniel Jacobowitz, amit bhor
IIRC, Unix SysV on an MC88000 did this. The kerenl would field an inprecise
interrupt and 'clean it up' so the the messeyness was not passed on to user
level code.
It's been a while, though, so I might be mis-remembering.
-=# Paul #=-
On Thursday 24 March 2005 12:23, Ramana Radhakrishnan wrote:
> Hi,
>
> > Isn't this usually handled by the kernel?
>
> How could this be handled by the kernel ? The point is that
> one needs to insert 4 instructions in the place of one for a
> software breakpoint and the mechanism mentioned in my
> earlier mail is possibly one of the methods . (The point is
> one cannot ignore the next 3 instructions in the pipeline
> since one of them could be a branch to some location , so a
> simple DECR_PC_AFTER_BREAK would not necessarily work always )
>
> Addr to set breakpoint: someinsn
> b bar
>
>
>
> Having said that, could you point me to any kernel that does
> this ?
>
>
>
> cheers
> Ramana
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: RFC : Handling breakpoints on archs. with imprecise exceptions.
2005-03-24 19:46 RFC : Handling breakpoints on archs. with imprecise exceptions Ramana Radhakrishnan
2005-03-24 19:57 ` Paul Gilliam
@ 2005-03-24 20:37 ` Daniel Jacobowitz
2005-03-24 22:46 ` Ramana Radhakrishnan
2005-03-24 21:30 ` Kevin Buettner
2 siblings, 1 reply; 9+ messages in thread
From: Daniel Jacobowitz @ 2005-03-24 20:37 UTC (permalink / raw)
To: Ramana Radhakrishnan; +Cc: gdb, amit bhor
On Fri, Mar 25, 2005 at 01:16:12AM +0530, Ramana Radhakrishnan wrote:
> 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?
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.
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.
Does gdbarch_read_pc do everything you need for the wait_hook? You can
update the PC from there if necessary.
--
Daniel Jacobowitz
CodeSourcery, LLC
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: RFC : Handling breakpoints on archs. with imprecise exceptions.
2005-03-24 20:37 ` Daniel Jacobowitz
@ 2005-03-24 22:46 ` Ramana Radhakrishnan
0 siblings, 0 replies; 9+ messages in thread
From: Ramana Radhakrishnan @ 2005-03-24 22:46 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb, amit bhor
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)
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: RFC : Handling breakpoints on archs. with imprecise exceptions.
2005-03-24 19:46 RFC : Handling breakpoints on archs. with imprecise exceptions Ramana Radhakrishnan
2005-03-24 19:57 ` Paul Gilliam
2005-03-24 20:37 ` Daniel Jacobowitz
@ 2005-03-24 21:30 ` Kevin Buettner
2 siblings, 0 replies; 9+ messages in thread
From: Kevin Buettner @ 2005-03-24 21:30 UTC (permalink / raw)
To: gdb
On Fri, 25 Mar 2005 01:16:12 +0530
Ramana Radhakrishnan <ramana.radhakrishnan@codito.com> wrote:
> 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.
Another approach, different from the one you outlined, is to use a
branch-to-self as the breakpoint instruction. The stub needs to
periodically check to see if the task being debugged is stopped at one
of these infinite loop instructions upon which a breakpoint has been
placed. If so, it interrupts the task and reports a SIGTRAP to GDB.
I know of at least one case where this was done - though, as I recall,
it was done because the processor provided no other suitable breakpoint
instruction.
This approach makes the stub somewhat more complicated, but has the
virtue of keeping the GDB implementation relatively simple.
Kevin
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: RFC : Handling breakpoints on archs. with imprecise exceptions.
@ 2005-03-24 23:31 Decker, Paul
2005-03-24 23:32 ` Daniel Jacobowitz
0 siblings, 1 reply; 9+ messages in thread
From: Decker, Paul @ 2005-03-24 23:31 UTC (permalink / raw)
To: Ramana Radhakrishnan, Daniel Jacobowitz; +Cc: gdb, amit bhor
Hi all,
Could you just save and restore 4 instructions for each breakpoint, and
have a jump back to the original breakpoint address minus 1?
opcode1
opcode2 << user breakpoint
opcode3
opcode4
opcode5
opcode6
--- stub does this replacement
opcode1
trap << user breakpoint
jump 0
jump -1
jump -2
opcode6
regards,
Paul.
-----Original Message-----
From: gdb-owner@sources.redhat.com [mailto:gdb-owner@sources.redhat.com]
On Behalf Of Ramana Radhakrishnan
Sent: Thursday, March 24, 2005 5:46 PM
To: Daniel Jacobowitz
Cc: gdb@sources.redhat.com; amit bhor
Subject: Re: RFC : Handling breakpoints on archs. with imprecise
exceptions.
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)
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: RFC : Handling breakpoints on archs. with imprecise exceptions.
2005-03-24 23:31 Decker, Paul
@ 2005-03-24 23:32 ` Daniel Jacobowitz
0 siblings, 0 replies; 9+ messages in thread
From: Daniel Jacobowitz @ 2005-03-24 23:32 UTC (permalink / raw)
To: Decker, Paul; +Cc: Ramana Radhakrishnan, gdb, amit bhor
On Thu, Mar 24, 2005 at 05:52:07PM -0500, Decker, Paul wrote:
> Hi all,
>
> Could you just save and restore 4 instructions for each breakpoint, and
> have a jump back to the original breakpoint address minus 1?
No. For instance, you will now hit the breakpoint if an instruction
two later in the stream is a branch target. Using more than one
instruction for a breakpoint is a real losing proposition.
--
Daniel Jacobowitz
CodeSourcery, LLC
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2005-03-24 23:32 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-03-24 19:46 RFC : Handling breakpoints on archs. with imprecise exceptions Ramana Radhakrishnan
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
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).