From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21141 invoked by alias); 7 Mar 2002 06:28:22 -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 20973 invoked from network); 7 Mar 2002 06:28:06 -0000 Received: from unknown (HELO deimos.hpl.hp.com) (192.6.19.190) by sources.redhat.com with SMTP; 7 Mar 2002 06:28:06 -0000 Received: from hplms2.hpl.hp.com (hplms2.hpl.hp.com [15.0.152.33]) by deimos.hpl.hp.com (8.9.3 (PHNE_24419)/HPL-PA Relay) with ESMTP id WAA11863 for ; Wed, 6 Mar 2002 22:28:05 -0800 (PST) Received: from wailua.hpl.hp.com (wailua.hpl.hp.com [15.4.89.122]) by hplms2.hpl.hp.com (8.10.2/8.10.2 HPL-PA Hub) with ESMTP id g276S5s14948; Wed, 6 Mar 2002 22:28:05 -0800 (PST) Received: from davidm by wailua.hpl.hp.com with local (Exim 3.34 #1 (Debian)) id 16irNk-0007hA-00; Wed, 06 Mar 2002 22:28:04 -0800 To: gdb@sources.redhat.com cc: davidm@hpl.hp.com Subject: question on gdbarch_skip_prologue() X-URL: http://www.hpl.hp.com/personal/David_Mosberger/ Reply-to: davidm@hpl.hp.com Message-Id: From: David Mosberger Date: Wed, 06 Mar 2002 22:28:00 -0000 X-SW-Source: 2002-03/txt/msg00037.txt.bz2 Hello, 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. Thanks, --david