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

["Decker, Paul" <Paul.Decker@analog.com>]

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)