Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Mark Kettenis <kettenis@gnu.org>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFC] DWARF2 unwinder on SPARC
Date: Mon, 07 Mar 2005 21:09:00 -0000	[thread overview]
Message-ID: <20050307210853.GA26899@nevyn.them.org> (raw)
In-Reply-To: <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


      reply	other threads:[~2005-03-07 21:09 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-07 21:03 Mark Kettenis
2005-03-07 21:09 ` Daniel Jacobowitz [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050307210853.GA26899@nevyn.them.org \
    --to=drow@false.org \
    --cc=gdb-patches@sources.redhat.com \
    --cc=kettenis@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox