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

On Wed, 13 Jul 2005 16:42:07 +0100, Daniel Jacobowitz <drow@false.org>  
wrote:

> On Wed, Jul 13, 2005 at 03:44:10PM +0100, Andrew STUBBS wrote:
>> With this function I get different wrong behaviour. Now I get all but PC
>> and R15 (stack pointer) as '*value not available*'. I had expected that
>> that the CFI would override the initialised values because it knows best
>> (just because it is called 'init', not 'set), but neither R14 nor PR  
>> have
>> their true values listed despite execute_cfa_program extracting a 'how'
>> value of DWARF2_FRAME_REG_SAVED_OFFSET. Clearly this is not the case,  
>> but
>> should it be?
>
> Why isn't it?  Please debug this, since reading the code clearly
> suggests it works as you expect.  See dwarf2_frame_cache.

I'll see what I can find.

>> I know the PR register is
>> technically caller save, but has a CFI entry in my test program, but  
>> then
>> in practice PR is really treated as callee save anyway. Is that just a
>> special case?
>
> I would need to see the CFI, sorry - I can't follow exactly what you
> mean.

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.

Thanks

Andrew Stubbs

  reply	other threads:[~2005-07-13 16:16 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 [this message]
2005-07-13 20:27             ` Daniel Jacobowitz
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=op.stu0pocho669wz@terrorhawk.bri.st.com \
    --to=andrew.stubbs@st.com \
    --cc=drow@false.org \
    --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).