From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11580 invoked by alias); 31 Jan 2002 22:27:37 -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 11547 invoked from network); 31 Jan 2002 22:27:36 -0000 Received: from unknown (HELO mail.sandvine.com) (209.167.74.226) by sources.redhat.com with SMTP; 31 Jan 2002 22:27:36 -0000 Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jan 2002 17:27:31 -0500 Message-ID: From: Don Bowman To: "'gdb@sources.redhat.com'" Subject: MIPS stack tracing Date: Thu, 31 Jan 2002 14:27: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-01/txt/msg00377.txt.bz2 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? --don