RFC : Handling breakpoints on archs. with imprecise exceptions.

RFC : Handling breakpoints on archs. with imprecise exceptions.

[Ramana Radhakrishnan]

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)

Re: RFC : Handling breakpoints on archs. with imprecise exceptions.

[Paul Gilliam]

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

Re: RFC : Handling breakpoints on archs. with imprecise exceptions.

[Ramana Radhakrishnan]

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)

Re: RFC : Handling breakpoints on archs. with imprecise exceptions.

[Daniel Jacobowitz]

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

Re: RFC : Handling breakpoints on archs. with imprecise exceptions.

[Kevin Buettner]

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

Re: RFC : Handling breakpoints on archs. with imprecise exceptions.

[Paul Gilliam]

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

Re: RFC : Handling breakpoints on archs. with imprecise exceptions.

[Ramana Radhakrishnan]

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)

Re: RFC : Handling breakpoints on archs. with imprecise exceptions.

[Daniel Jacobowitz]

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

RE: RFC : Handling breakpoints on archs. with imprecise exceptions.

[Decker, Paul]

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)