From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11050 invoked by alias); 16 Sep 2008 18:35:14 -0000 Received: (qmail 11036 invoked by uid 22791); 16 Sep 2008 18:35:13 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-2.vmware.com (HELO smtp-outbound-2.vmware.com) (65.115.85.73) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 16 Sep 2008 18:34:37 +0000 Received: from mailhost2.vmware.com (mailhost2.vmware.com [10.16.64.160]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 15447C00E; Tue, 16 Sep 2008 11:34:36 -0700 (PDT) Received: from [10.20.92.218] (promb-2s-dhcp218.eng.vmware.com [10.20.92.218]) by mailhost2.vmware.com (Postfix) with ESMTP id 0AD348E5FB; Tue, 16 Sep 2008 11:34:36 -0700 (PDT) Message-ID: <48CFFBCA.4080109@vmware.com> Date: Tue, 16 Sep 2008 18:35:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Qiu Feng CC: "gdb@sourceware.org" Subject: Re: MIPS stub problem References: <4D79C9B593D04500AF1FD6DCEF5EB430@fqiux61> In-Reply-To: <4D79C9B593D04500AF1FD6DCEF5EB430@fqiux61> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-09/txt/msg00109.txt.bz2 Qiu Feng wrote: > Hi all, > > I am implementing a stub for mips. I found epc always contains the position > of next instuction after the inserted "break", I wonder if PC client gdb > will take it into acount? Should I manually rollback the epc to the location > of replaced original instruction? Hmmm. I'm rusty here, but I don't think that's the norm for MIPS. What exact mips part is this? There are two classes of processors -- those which point to the trap instruction itself after taking a trap, and those that point to the next instruction following the trap insn. GDB accounts for this difference with a configuration variable called DECR_PC_AFTER_BREAK ("decrement the PC after a breakpoint"). It's true for i386, for instance, but not normally for mips. > Another question, does pc side GDB only read local varibles by offset of SP > (should be $29)? Again, my MIPS foo is rusty, but its likely that gdb may also read local variables by offset from a frame pointer reg.