From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29066 invoked by alias); 24 Mar 2005 22:46:30 -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 29023 invoked from network); 24 Mar 2005 22:46:24 -0000 Received: from unknown (HELO calvin.codito.co.in) (220.225.32.98) by sourceware.org with SMTP; 24 Mar 2005 22:46:24 -0000 Received: from [192.168.100.52] (ramana.codito.co.in [192.168.100.52]) by calvin.codito.co.in (8.12.10/8.12.10) with ESMTP id j2OMkH89025056; Fri, 25 Mar 2005 04:16:17 +0530 Message-ID: <42434333.4000908@codito.com> Date: Thu, 24 Mar 2005 22:46:00 -0000 From: Ramana Radhakrishnan User-Agent: Mozilla Thunderbird 0.8 (X11/20040926) MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb@sources.redhat.com, amit bhor Subject: Re: RFC : Handling breakpoints on archs. with imprecise exceptions. References: <42431904.7010708@codito.com> <20050324203814.GA7529@nevyn.them.org> In-Reply-To: <20050324203814.GA7529@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-03/txt/msg00220.txt.bz2 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)