This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC] DWARF2 unwinder on SPARC
- From: Daniel Jacobowitz <drow at false dot org>
- To: Mark Kettenis <kettenis at gnu dot org>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Mon, 7 Mar 2005 16:08:53 -0500
- Subject: Re: [RFC] DWARF2 unwinder on SPARC
- References: <200503072103.j27L3i4x004351@elgar.sibelius.xs4all.nl>
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