This is the mail archive of the 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?

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).



Daniel Jacobowitz wrote:
On Thu, Apr 03, 2008 at 10:35:41PM +0100, Antony KING wrote:

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]