public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Andrew STUBBS <andrew.stubbs@st.com>
Cc: GDB <gdb@sources.redhat.com>
Subject: Re: Invalid registers
Date: Wed, 13 Jul 2005 20:27:00 -0000	[thread overview]
Message-ID: <20050713202716.GA8536@nevyn.them.org> (raw)
In-Reply-To: <op.stu0pocho669wz@terrorhawk.bri.st.com>

On Wed, Jul 13, 2005 at 05:14:02PM +0100, Andrew STUBBS wrote:
> The SH ABI lists the PR register (in which the PC is saved by a branch to  
> subroutine) as caller save. This is true because a function has to save it  
> before calling a subroutine. However, in practice it can be viewed as a  
> callee save register because all non-leaf functions save it in the  
> function prologue. GCC appears to be emitting CFI information for PR as if  
> it was callee save.
> 
> You say that there should be no CFI for caller saved registers, so I'll  
> take that as answering my question.

Sorry, at some point you got me turned around with my own terminology. 
Let me try again, more coherently.

CFI describes saved registers.  It can describe any saved register;
typically, however, it only describes enough state to unwind to the
state as-of any call instruction, i.e. to describe any frame on the
stack.  At a call instruction there is still code in the caller to be
executed which will reload the caller saved registers; that code can be
freely scheduled, it is not part of the call sequence.  So typically it
is not described.  Those registers are dead at the call site and given
interesting values again later.

While the registers may be conceptually unavailable, the variables in
them are not - if your compiler emits good location lists, they'll
reflect the stack slots used.

So the value for PR we want to recover while unwinding is the value it
had "at the call site" - generally unavailable.  But we can figure out
what it was just after the call site, where the prologue will often
have saved it, and use that to determine where to unwind to.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

  reply	other threads:[~2005-07-13 20:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-11 15:42 Andrew STUBBS
2005-07-11 15:49 ` Daniel Jacobowitz
2005-07-11 18:47   ` Marcel Moolenaar
2005-07-11 18:51     ` Daniel Jacobowitz
2005-07-11 19:08       ` Marcel Moolenaar
2005-07-12 16:16     ` Andrew STUBBS
2005-07-12 17:19       ` Marcel Moolenaar
2005-07-12 16:07   ` Andrew STUBBS
2005-07-12 17:34     ` Daniel Jacobowitz
2005-07-13 15:13       ` Andrew STUBBS
2005-07-13 15:42         ` Daniel Jacobowitz
2005-07-13 16:16           ` Andrew STUBBS
2005-07-13 20:27             ` Daniel Jacobowitz [this message]
2005-07-14  9:36           ` Andrew STUBBS
2005-07-14 14:11             ` Daniel Jacobowitz

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=20050713202716.GA8536@nevyn.them.org \
    --to=drow@false.org \
    --cc=andrew.stubbs@st.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).