Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Con Bradley <ceb@clearspeed.com>
Cc: gdb@sources.redhat.com
Subject: Re: Dwarf 2 Stack pointer unwind.
Date: Tue, 01 Feb 2005 17:25:00 -0000	[thread overview]
Message-ID: <20050201172451.GA2513@nevyn.them.org> (raw)
In-Reply-To: <734804467.20050201171842@clearspeed.com>

On Tue, Feb 01, 2005 at 05:18:42PM +0000, Con Bradley wrote:
> Hi,
>    We have an ABI where the stack pointer is never saved to the stack
> on a function call and there is NO frame pointer. Instead the stack is
> maintained by stack pointer increments and decrements.
> How does one describe this in Dwarf Call Frame Instructions? The only
> rules available for register operations are to save on the stack or to
> copy to another register. No rules to describe plus or negative
> register adjustments.
> 
>   I find it difficult to understand why there is no support for this
> in Dwarf 2 or Dwarf 3 as this must be a common idiom.

I recommend you asking this on the dwarf2 mailing list instead of here.

> When we adjust the stack pointer we issue CFA_CFA_def_cfa operations
> to describe the new rule to access the CFA, effectively issuing a CFA
> rule to compensate for the stack pointer being changed. This is
> sufficient to allow stack unwind to work. However, when we look up the
> values of automatics in upper stack frames this fails. The reason
> being that the address of these variables (in location expressions) is given
> as an offset from the stack pointer but there appear to be no unwind
> rules for the stack pointer register.
> 
> More correctly we'd like to say that the address of an automatic was
> CFA plus offset but there doesn't appear to be any support for this.
> 
> How does one describe stack pointer changes which do not involve
> saving on the stack or use of a frame pointer.

A couple of ways to link the frame base (DW_AT_frame_base) to the CFA
have been proposed.  Nothing's been picked yet though.

To see how this is handled in GDB, look at
dwarf2_frame_default_init_reg.  By setting SP_REGNUM's rule to
DWARF2_FRAME_REG_CFA, we have the value of the stack pointer for the
frame.  Then you can define appropriate DW_AT_frame_base values and use
DW_OP_fbreg.

-- 
Daniel Jacobowitz


      reply	other threads:[~2005-02-01 17:25 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-01 17:20 Con Bradley
2005-02-01 17:25 ` 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=20050201172451.GA2513@nevyn.them.org \
    --to=drow@false.org \
    --cc=ceb@clearspeed.com \
    --cc=gdb@sources.redhat.com \
    /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