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 15:13:00 -0000	[thread overview]
Message-ID: <op.stuwjwguo669wz@terrorhawk.bri.st.com> (raw)
In-Reply-To: <20050712173450.GA1486@nevyn.them.org>

On Tue, 12 Jul 2005 18:34:50 +0100, Daniel Jacobowitz <drow@false.org>  
wrote:
> Sorry, not enough information - I'd need specifics.  GCC's CFI
> generally does not represent call-clobbered registers; waste of space
> for a runtime unwinder.

Ok, after further investigation, here's what I'm seeing.

The default init_reg function, dwarf2_frame_default_init_reg, sets up the  
PC and stack pointer registers so that they do the right thing.  
Additionally, the CFI information describes how the R14 (frame pointer)  
and PR (saved PC) registers are saved to the stack.

With this setup, 'frame 1' followed by 'info all-registers' shows the  
correct values (I assume) for the four registers above, and (potentially)  
incorrect values for everything else.

So I set up a function, as follows, to tell it that anything is invalid,  
unless it knows otherwise:

sh_dwarf2_frame_init_reg (struct gdbarch *gdbarch, int regnum,
                             struct dwarf2_frame_state_reg *reg)
{
   /* Mark PC as destination for the return address.  */
   if (regnum == PC_REGNUM)
     reg->how = DWARF2_FRAME_REG_RA;

   /* Mark stack pointer set it to the call frame address.  */
   else if (regnum == SP_REGNUM)
     reg->how = DWARF2_FRAME_REG_CFA;

   /* Mark all other registers as invalid.
      Braindead, but ok for now.  */
   else
     reg->how = DWARF2_FRAME_REG_UNDEFINED;
}

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?

Obviously the function above is overkill, in any case, because callee  
saved registers always have a useful value in them - either they have not  
changed or they have been saved and the CFI knows about it. I could fix  
that by just looking up exactly which they are and encoding it into the  
function above.

However, it is not clear to me what to do with caller save registers. If I  
just set them to undefined, as above, then they will never have a value,  
but are there sometimes saved values for those registers (saved by the  
caller) and cannot CFI describe this? In short, is it always the case that  
call clobblered registers are unavailable? 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?

Thanks

Andrew Stubbs

  reply	other threads:[~2005-07-13 15:13 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 [this message]
2005-07-13 15:42         ` Daniel Jacobowitz
2005-07-13 16:16           ` Andrew STUBBS
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.stuwjwguo669wz@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).