From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12840 invoked by alias); 24 Mar 2005 23:31:00 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 12773 invoked from network); 24 Mar 2005 23:30:50 -0000 Received: from unknown (HELO nwd2mail1.analog.com) (137.71.25.50) by sourceware.org with SMTP; 24 Mar 2005 23:30:50 -0000 Received: from nwd2mhb2.analog.com (nwd2mhb2.analog.com [137.71.6.12]) by nwd2mail1.analog.com (8.12.10/8.12.10) with ESMTP id j2ON1GpY011993; Thu, 24 Mar 2005 18:30:31 -0500 Received: from nwd2exm3.ad.analog.com (nwd2exm3.ad.analog.com [10.64.51.19]) by nwd2mhb2.analog.com (8.9.3 (PHNE_28810+JAGae91741)/8.9.3) with ESMTP id RAA20026; Thu, 24 Mar 2005 17:52:09 -0500 (EST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RFC : Handling breakpoints on archs. with imprecise exceptions. Date: Thu, 24 Mar 2005 23:31:00 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Decker, Paul" To: "Ramana Radhakrishnan" , "Daniel Jacobowitz" Cc: , "amit bhor" X-Spam-Status: No, hits=-102.8 required=10.0 tests=ALL_TRUSTED,USER_IN_WHITELIST version=3.0.2 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 3.000002 (2004-11-16) X-SW-Source: 2005-03/txt/msg00226.txt.bz2 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=20 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=20 >>exceptions/ interrupts i.e. the equivalent of a software breakpoint=20 >>would require 4 instructions to stop. >>With my research I was unable to find any GDB port that needed to=20 >>handle such a case. >> >>The mechanism that is in mind is the following for setting=20 >>breakpoints. >=20 >=20 > 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 . ) >=20 > 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=20 > 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=20 > hooks in target_insert_breakpoint/target_remove_breakpoint to=20 > reference count. >=20 >=20 >>a. Define gdbarch_adjust_breakpoint_address in the backend to store=20 >>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=20 >>to have been hit. >> >>b. Define deprecated_target_wait_hook in the backend to restore the=20 >>actual value of the PC for GDB to continue with its work.However as=20 >>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=20 >>needs notification for the breakpoint being deleted and hence free an=20 >>entry in the breakpoint table. >=20 >=20 > You should be hooking insert/remove breakpoint, not add/delete user=20 > breakpoint. Aha! that would be because for one, breakpoints for single stepping need not necessarily be in the breakpoint table . >=20 > Does gdbarch_read_pc do everything you need for the wait_hook? You=20 > can update the PC from there if necessary. >=20 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)