From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6981 invoked by alias); 7 Mar 2005 21:09:00 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 6939 invoked from network); 7 Mar 2005 21:08:57 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 7 Mar 2005 21:08:57 -0000 Received: from drow by nevyn.them.org with local (Exim 4.44 #1 (Debian)) id 1D8PTB-00072b-9a; Mon, 07 Mar 2005 16:08:53 -0500 Date: Mon, 07 Mar 2005 21:09:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] DWARF2 unwinder on SPARC Message-ID: <20050307210853.GA26899@nevyn.them.org> Mail-Followup-To: Mark Kettenis , gdb-patches@sources.redhat.com References: <200503072103.j27L3i4x004351@elgar.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503072103.j27L3i4x004351@elgar.sibelius.xs4all.nl> User-Agent: Mutt/1.5.6+20040907i X-SW-Source: 2005-03/txt/msg00096.txt.bz2 On Mon, Mar 07, 2005 at 10:03:44PM +0100, Mark Kettenis wrote: > I'm working on enabling the DWARF2 unwinder on 32-bit and 64-bit > SPARC. It's basically working for me on FreeBSD/sparc64, but there > are two issues that I'd like some opinions about. > > 1. I'll need to handle DW_CFA_GNU_window_save. I suppose its > interpretation will be really machine specific, but it really only > makes sense for register window architectures. And I can only > think of a single example of such an architecture that's still > around. Now the problem I'm facing is the choice between two > evils: > > a. Contaminate dwarf2-frame.c with a bit of target-specific code. > > b. Contaminate dwarf2-frame.c with another architecture-specific > operation that will only be used for SPARC. > > Can someone make a choice for me ;-) I'd just do (A). Nothing but GCC generates it; GCC generates it only for SPARC; hopefully no one will ever raise the issue for another platform. A comment that the magic numbers refer to SPARC would be nice though. > 2. We need a mechanism for return addresses that are not quite the > contents of a register or memory slot. On SPARC, the address of > the call instruction is stored in a register instead of the address > where we should return to. So the proper way to unwind the pc is > to take this register and add 8 to it. There's also npc, which > should be calculated in a similar way by adding 12. We'll need > something similar for PA-RISC and m88k will need it too if it ever > gains a dwarf2 unwinder. There might be more architectures out > there that need this. > > My proposal is to change the definition of DWARF2_FRAME_REG_RA such > that the offset member of `struct dwarf2_frame_state_reg' can be > used to specify the amount to add to the value yielded by the > return address column. This is compatible with the existing use > since currently that offset member is initialized to zero. As an > alternative, we can add a new constant DWARF2_FRAME_REG_RA_OFFSET > for this usage. I would persoally prefer DWARF2_FRAME_REG_RA_OFFSET. -- Daniel Jacobowitz CodeSourcery, LLC