This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problem setting registers if stack point or frame pointer is 0


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 :-(


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]