From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20694 invoked by alias); 1 Feb 2002 19:32:59 -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 20526 invoked from network); 1 Feb 2002 19:32:50 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 1 Feb 2002 19:32:50 -0000 Received: from drow by nevyn.them.org with local (Exim 3.34 #1 (Debian)) id 16WjQh-000071-00; Fri, 01 Feb 2002 14:32:59 -0500 Date: Fri, 01 Feb 2002 11:32:00 -0000 From: Daniel Jacobowitz To: Don Bowman Cc: "'gdb@sources.redhat.com'" Subject: Re: MIPS stack tracing Message-ID: <20020201143259.B32707@nevyn.them.org> Mail-Followup-To: Don Bowman , "'gdb@sources.redhat.com'" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i X-SW-Source: 2002-02/txt/msg00043.txt.bz2 On Fri, Feb 01, 2002 at 01:14:44PM -0500, Don Bowman wrote: > > 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. For embedded systems, you'd have to disable the multiple-return optimizations. This is actually very simple to do, though I don't remember off-hand. If you ask on gcc@gcc.gnu.org what change it is you would need to make to the MD file to get a compiler that didn't do this, I'm sure they can tell you. If you argue convincingly enough they might even revert (or at least add a flag). This is not the right way for GDB to backtrace, however. On most architectures GDB gets a very minimal backrace with no symbols; I personally am fine with giving none at all. Does anyone out there really object? -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer