From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17561 invoked by alias); 2 Feb 2002 19:26:21 -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 17526 invoked from network); 2 Feb 2002 19:26:21 -0000 Received: from unknown (HELO mail.sandvine.com) (209.167.74.226) by sources.redhat.com with SMTP; 2 Feb 2002 19:26:21 -0000 Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Sat, 2 Feb 2002 14:26:15 -0500 Message-ID: From: Don Bowman To: 'Greg McGary' , Don Bowman Cc: 'Daniel Jacobowitz' , gdb@sources.redhat.com, echristo@redhat.com Subject: RE: MIPS stack tracing Date: Sat, 02 Feb 2002 11:26:00 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-SW-Source: 2002-02/txt/msg00054.txt.bz2 > Greg McGary 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. I've personally never observed multiple returns prior to 3.0, but perhaps I had some optimisation disabled which caused it. I don't think you're correct about the no-multiple returns when there's a frame. Here's a snippet of assembly from a function of mine. As you can see, the stack is adjusted by 64 at the top. There is an interior return which deadjusts the stack, and there's more further down in the function. : 0080102d move v0,a0 24470004 addiu a3,v0,4 27bdffc0 addiu sp,sp,-64 00a0402d move t0,a1 ... afa00030 sw zero,48(sp) dfbf0038 ld ra,56(sp) 03e00008 jr ra 27bd0040 addiu sp,sp,64 00000000 nop 0c000000 jal 0 ... I've been debugging through gdb for a day or so now, I think I'm on to something. It appears that find_proc_desc is switching to the heuristic approach even though I have a symbol table. It sucessfully find the symbols, but given a PC, can't find the symbol that its in. This may be due to the sign-extension on the addresses (eg ffffffff80000000). I'm hoping to get a fix for gdb today and send in a patch. --don