From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12656 invoked by alias); 7 Mar 2002 08:12:03 -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 12503 invoked from network); 7 Mar 2002 08:11:57 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 7 Mar 2002 08:11:57 -0000 Received: from cse.cygnus.com (cse.cygnus.com [205.180.230.236]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id AAA23357; Thu, 7 Mar 2002 00:11:27 -0800 (PST) Received: (from kev@localhost) by cse.cygnus.com (8.11.6/8.11.6) id g278BHd26474; Thu, 7 Mar 2002 01:11:17 -0700 Date: Thu, 07 Mar 2002 00:12:00 -0000 From: Kevin Buettner Message-Id: <1020307081116.ZM26473@localhost.localdomain> In-Reply-To: David Mosberger "question on gdbarch_skip_prologue()" (Mar 6, 10:28pm) References: X-Mailer: Z-Mail (4.0.1 13Jan97 Caldera) To: davidm@hpl.hp.com, gdb@sources.redhat.com Subject: Re: question on gdbarch_skip_prologue() MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-03/txt/msg00042.txt.bz2 On Mar 6, 10:28pm, David Mosberger wrote: > I'm exploring the idea of changing the ia64 backend of gdb to use > unwind information instead of code-reading. While looking into this, > I started to wonder how gdbarch_skip_prologue() should be implemented. > Some backends simply return the PC that was passed into the routine, > i.e., they always assume a zero-size prologue. I'm tempted to do the > same because I worry that with optimized code, the very notion of a > prologue becomes quite fuzzy. For example, a prologue might contain a > branch and, if so, there may not even be a single PC that corresponds > to the end of the prologue. > > Are there any downsides to gdbarch_skip_prologue() always returning > the original PC? Since the unwind info is accurate no matter what the > PC is, there are no problems with tracking the contents of preserved > (callee-saved) registers, but I'm wondering whether I'm missing > anything else. GDB currently expects that the skip_prologue() function will return a PC that's after the last prologue instruction that saved an argument to its "home" location (if any) in memory (or whereever the debug info says that a parameter's location is). The difficulty with this, of course, is that with optimized code, it can be very difficult to discern where this is. Kevin