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: Thu, 14 Jul 2005 09:36:00 -0000	[thread overview]
Message-ID: <op.stwctznyo669wz@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 think I have found the 'problem'.

It is working as it should, but it doesn't look like it at first sight.  
When I set a breakpoint on a function it breaks _before_ the callee save  
registers have been saved (this may be a mistake, I'm not sure yet). If I  
step into the function a little more then the CFI kicks in and it  
overrides the initial settings I put in.

What confused my is that there is more than one frame available at once  
(of course), and when debugging it is not always clear which one I am  
looking at, especially when it is typically the same set of registers  
being saved.

Thank you for all your help. Apologies for being thick.

Now onto the next issue ....

Andrew Stubbs

  parent reply	other threads:[~2005-07-14  9:36 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
2005-07-14  9:36           ` Andrew STUBBS [this message]
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.stwctznyo669wz@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).