From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31695 invoked by alias); 15 Jun 2007 14:38:00 -0000 Received: (qmail 31686 invoked by uid 22791); 15 Jun 2007 14:38:00 -0000 X-Spam-Check-By: sourceware.org Received: from dmz.mips-uk.com (HELO dmz.mips-uk.com) (194.74.144.194) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 15 Jun 2007 14:37:56 +0000 Received: from internal-mx1 ([192.168.192.240] helo=ukservices1.mips.com) by dmz.mips-uk.com with esmtp (Exim 3.35 #1 (Debian)) id 1HzCvv-0001tk-00; Fri, 15 Jun 2007 15:37:51 +0100 Received: from perivale.mips.com ([192.168.192.200]) by ukservices1.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1HzCvm-0002IF-00; Fri, 15 Jun 2007 15:37:42 +0100 Received: from macro (helo=localhost) by perivale.mips.com with local-esmtp (Exim 4.63) (envelope-from ) id 1HzCvm-0002Od-Td; Fri, 15 Jun 2007 15:37:42 +0100 Date: Fri, 15 Jun 2007 14:38:00 -0000 From: "Maciej W. Rozycki" To: Daniel Jacobowitz cc: gdb-patches@sourceware.org, Chris Dearman , "Maciej W. Rozycki" Subject: Re: mips-tdep.c: Adjust breakpoints in branch delay slots In-Reply-To: <20070525131910.GA28994@caradoc.them.org> Message-ID: References: <20070524183129.GA10094@caradoc.them.org> <20070525131910.GA28994@caradoc.them.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MIPS-Technologies-UK-MailScanner: Found to be clean X-MIPS-Technologies-UK-MailScanner-From: macro@mips.com Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-06/txt/msg00291.txt.bz2 On Fri, 25 May 2007, Daniel Jacobowitz wrote: > > FYI, I have now checked Linux and it should be fine -- must have been my > > bad memory. EJTAG has provisions for handling this correctly > > (cp0.debug.dbd), but I'm not sure if associated software gets it right. EJTAG seems to be getting it right in principle -- there is one corner case affecting us which I have identified, but it should be taken care of elsewhere. > Great. Want to take a look at doing this the other way then? As much as I'd like to I may not be able to do it right now. > The best option I can think of would be to fake the PC value based on > the value of BD. You might be able to do this cleverly; have a > register named "$pc" which shows the hardware contents of the PC > register, and have read_pc / unwind_pc / write_pc adjust based on BD. Note that there is nothing special needed for write_pc -- if you modify the PC, you just write the new value to the "register" (there is actually no such register as the PC in the MIPS architecture -- it's merely a useful notion of "the next instruction to execute", which depending on the way a debugger accesses the processor may happen to be recorded in various cp0 registers). BD is a merely a status bit which does not affect subsequent ERET/DERET. > I'm not sure if that will work, but it does mimic the architecture > behavior, which is an encouraging sign; and some other platforms do > similar magic (e.g. HP/UX and IA64). This is not rocket science -- the basic issue is to make gdb "accept" a breakpoint that signals at a different address to one it was set at. > It might be best to eliminate the setting of PC_REGNUM first, but > that's multi-arch work; I see that dwarf2-frame.c relies on it unless > you set dwarf2_frame_default_init_reg. I am not sure what you mean here... Maciej