From: Antony KING <antony.king@st.com>
To: gdb@sourceware.org
Subject: Re: Problem setting registers if stack point or frame pointer is 0
Date: Fri, 04 Apr 2008 11:43:00 -0000 [thread overview]
Message-ID: <47F6101A.1020505@st.com> (raw)
In-Reply-To: <20080403214752.GA20869@caradoc.them.org>
Thanks for the information. Is the hack you mention the suggestion (you
gave to my colleague) in the following response?
http://www.cygwin.com/ml/gdb-patches/2006-05/msg00018.html
We did have this patch applied at some point in earlier versions of our
GDB but we seem to have lost it along the way :-(.
Anyway it looks to be a better solution than the one I suggested (as
every user of frame_find_by_id() will benefit), so I will reapply it to
our version of GDB (unless you have a better version).
Cheers,
Antony.
Daniel Jacobowitz wrote:
> On Thu, Apr 03, 2008 at 10:35:41PM +0100, Antony KING wrote:
>> Hi,
>>
>> I have a problem trying to set a CPU register (using the GDB convenience
>> variable mechanism) if the stack pointer (SP) or frame pointer (FP) CPU
>> registers are 0. For example on an SH-4 device, where the FP register is
>> R14 and the SP register is R15, I see the following error from GDB
>> (6.7.1):
>
> This is an unfortunate design problem in GDB. You've found the right
> comment, but in fact the comment lies.
>
> /* ZERO denotes the null frame, let the caller decide what to do
> about it. Should it instead return get_current_frame()? */
>
> It doesn't denote just the null frame (nothing running). It also
> denotes the last frame (can not unwind past here, outermost). We've
> really got to get rid of that ambiguity.
>
> I use a terrible hack in find_frame_by_id in our tools, since I
> still haven't found time to return to this problem :-(
next prev parent reply other threads:[~2008-04-04 11:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-04 2:21 Antony KING
2008-04-04 2:30 ` Daniel Jacobowitz
2008-04-04 11:43 ` Antony KING [this message]
2008-04-04 17:37 ` 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=47F6101A.1020505@st.com \
--to=antony.king@st.com \
--cc=gdb@sourceware.org \
/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