This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]