From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16910 invoked by alias); 1 Feb 2002 17:37:11 -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 16604 invoked from network); 1 Feb 2002 17:36:57 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 1 Feb 2002 17:36:57 -0000 Received: from drow by nevyn.them.org with local (Exim 3.34 #1 (Debian)) id 16WhcZ-0007W4-00; Fri, 01 Feb 2002 12:37:07 -0500 Date: Fri, 01 Feb 2002 09:37:00 -0000 From: Daniel Jacobowitz To: Don Bowman Cc: "'gdb@sources.redhat.com'" Subject: Re: MIPS stack tracing Message-ID: <20020201123707.A28873@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/msg00037.txt.bz2 On Thu, Jan 31, 2002 at 05:27:30PM -0500, Don Bowman wrote: > > The MIPS / vxworks stack tracing has always been fairly weak > in gdb I've found. However, now with the 3.0.3 gdb, it > is quite broken. > > The problem is that the compiler emits multiple returns > per function. The algorithm gdb follows is that specified > by the SYSV ABI (which the compiler is breaking). I looked > into fixing the compiler, but gave up in the short term. > In desperation I added a magic instruction (break 4) in the > epilogue of each function (by modifying gcc). This allowed > me to fix my VxWorks task trace (tt). > > 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? > The alternative is I can add support for walking to find > my magic instruction. This isn't standard. > The only other alternative I can see is to fix gcc up > to not emit multiple returns. This seems to be difficult to > add as a constraint. > > Does anyone have any suggestions on a course of action > for me to take? 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. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer