From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6190 invoked by alias); 1 Feb 2002 18:15:04 -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 6134 invoked from network); 1 Feb 2002 18:15:00 -0000 Received: from unknown (HELO mail.sandvine.com) (209.167.74.226) by sources.redhat.com with SMTP; 1 Feb 2002 18:15:00 -0000 Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Feb 2002 13:14:49 -0500 Message-ID: From: Don Bowman To: 'Daniel Jacobowitz' , Don Bowman Cc: "'gdb@sources.redhat.com'" Subject: RE: MIPS stack tracing Date: Fri, 01 Feb 2002 10:15: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/msg00039.txt.bz2 > From: Daniel Jacobowitz [mailto:drow@mvista.com] > > I'd like to understand - and have documented somewhere - what it is > about MIPS besides the somewhat-variable frame register that makes > backtracing so much more complex. Also, IMHO, if we have symbol > information to find the start of the function we should certainly use > it. 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. For embedded platforms this is a disaster: you don't have the full symbols (or sometimes any symbols). In desperation I added a function end marker of 'break 4', and search for that instead of 'jr ra'. This is obviously a hack, but I was stuck on our embedded system. Now I've got the same issue with gdb. I don't want to add the 'hack'. The algorithm its using just doesn't work. gdb in general has access to the symbols, so I can search for a .ent by symbol instead of by algorithm. However, this means gdb won't be able to work without symbols if I make the change. But it would appear that it doesn't right now anyway. --don