From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13232 invoked by alias); 2 Feb 2002 19:16:29 -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 13199 invoked from network); 2 Feb 2002 19:16:29 -0000 Received: from unknown (HELO kayak.mcgary.org) (63.227.80.137) by sources.redhat.com with SMTP; 2 Feb 2002 19:16:29 -0000 Received: (from gkm@localhost) by kayak.mcgary.org (8.11.6/8.11.2) id g12JGO111929; Sat, 2 Feb 2002 12:16:24 -0700 X-Authentication-Warning: kayak.mcgary.org: gkm set sender to greg@mcgary.org using -f To: Don Bowman Cc: "'Daniel Jacobowitz'" , gdb@sources.redhat.com, echristo@redhat.com, greg@mcgary.org Subject: Re: MIPS stack tracing References: From: Greg McGary Date: Sat, 02 Feb 2002 11:16:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-02/txt/msg00053.txt.bz2 Don Bowman writes: > The gist of it is, walk backwards until you find 'jr ra', > then walk forwards to the first non-null instruction. That's > the start of a function. Look for a [d]addiu to the sp, that's > the stack adjustment, look for a [d]addiu to the fp, that's > the frame. Look for a s[w|d] of ra to the stack. > Continue on up the stack. > > However, gcc 3.0 is breaking the rules. It emits multiple > 'jr ra' per function. Unfortunately, this appears to be > rather tough to fix. The upshot is that the beginning of > a function can't be reliably found, and it all falls apart > from there. Prior to gcc 3.0 it was fine. [ Cc'd to Eric Christopher who has a hand in the MIPS GCC backend, and with whom I briefly discussed this very issue a couple weeks ago. ] Hmm... GCC emitted multiple returns for MIPS long before 3.0. I recall first observing it in early 1998, and it had probably done it before. Maybe GCC 3.0 does it more often? Anyway, I had the same gripe about multiple returns breaking the ABI, but since then I have had second thoughts that perhaps this isn't a real problem. I haven't looked at MIPS code recently, so don't know for certain if my reasoning here is correct. Since you have had your nose buried in the code, you can tell me if my argument makes sense: If a function has a frame, it never has multiple returns. It always branches to the epilogue where the call frame is torn down. So, if a function has multiple returns, that means it is frameless, i.e. there's no prologue or epilogue. Say you scan backward within a frameless function. You might hit an interior `jr $ra' or the one that terminates the previous function. When you then scan forward, you'll find no stack adjustment and no store of $ra in any case. In call cases, you get the same answer: this function has no frame. Therefore, multiple returns are harmless since they give no false information about the call frame. OTOH, Something that can cause trouble is the GCC block-reordering optimization. This can cause the epilogue to be located in the middle of a function. You can defeat it with `GCC -fno-reorder-blocks'. Greg