From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9909 invoked by alias); 2 Feb 2002 18:58:58 -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 9868 invoked from network); 2 Feb 2002 18:58:57 -0000 Received: from unknown (HELO zok.sgi.com) (204.94.215.101) by sources.redhat.com with SMTP; 2 Feb 2002 18:58:57 -0000 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g12Iwvo26483 for ; Sat, 2 Feb 2002 10:58:57 -0800 Received: from quasar.engr.sgi.com (quasar.engr.sgi.com [130.62.180.91]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id KAA76267 for ; Sat, 2 Feb 2002 10:58:00 -0800 (PST) Received: (from davea@localhost) by quasar.engr.sgi.com (SGI-8.9.3/8.9.3) id KAA55020 for gdb@sources.redhat.com; Sat, 2 Feb 2002 10:58:36 -0800 (PST) Date: Sat, 02 Feb 2002 10:58:00 -0000 From: David Anderson Message-Id: <200202021858.KAA55020@quasar.engr.sgi.com> To: gdb@sources.redhat.com Subject: MIPS stack tracing X-SW-Source: 2002-02/txt/msg00052.txt.bz2 Don Bowman writes: > Now, before I launch into fixing the gdb MIPS stack tracing > code up, I thought I'd ask a few questions. I'd like to > do it by using the symbols to find the start of each function, > instead of by the heuristic of walking in the code. That > would be much faster for me (I'm on an embedded platform, > and its slow to walk the memory over the link). It would also > be deterministic. The downside is that the stack trace won't > work without a symbol file. Is that OK? Whether it's ok for gdb is for others to say. SGI debuggers long ago went this route. Daniel Jacobowitz writes: |The stack tracing algorithm for MIPS is defined in |the SYSV ABI, @ http://www.caldera.com/developers/devspecs/ |Its fairly straightforward and works reliably. | |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. That ABI document was written for and applies to the MIPS-I processors available at the time. AFAIK, the organization that maintained that document disbanded a few years ago. As I said in an earlier note, the ABI document was not always honored (though it should have been) even back in the early 1990's but today that Mips Processor Supplement is simply not applicable. Much has not changed, but key things have changed (new registers and new instructions). I don't know of a replacement document (other than SGI documents). http://www.mips.com has the MIPSpro assembly language document (vol 1 and 2) which is (or was) an SGI document describing the n32 calling conventions. (you have to register to see the document, but there is no charge). Also available from http://techpubs.sgi.com Corrections welcome. David Anderson davea@sgi.com