Re: Handling the 'next' command on a variable-length bundles target

[Daniel Jacobowitz <drow@false.org>]

On Tue, May 24, 2005 at 10:15:23AM +0200, Christophe LYON wrote:
> 
> > > I would like to have your inputs on possible
> > > clean ways of handling this.
> > > I am considering modyfing the way 'next' and
> > > 'stepi' memorize the frame in this specific
> > > case, but this is far from being generic.
> > > Maybe it is too specific to think of a generic
> > > fix, but maybe some of you have similar
> > > features?
> > 
> > This is not a missing feature in GDB, it's a bug in your target.  The
> > ID for a frame should be constant throughout the function.  You need to
> > use either code analysis or DWARF-2 style unwind information to have a
> > constant ID for the frame; in this case, probably the unadjusted SP.
> > 
> 
> Well, I am not (yet) very familiar with debugging optimized code.
> 
> What do you mean by "code analysis" ?
> 
> Currently, the recorded frame contains the unadjusted SP, but
> upon return from the call SP has been modified and the current
> frame is thus different from the recorded one. As you say
> the frame ID should be the unadjusted SP, I don't understand
> exactly how: you mean that after the call the frame ID should
> also contain the unadjusted SP?

Yes.  You might want to look at how DWARF-2 unwind information works;
the "stack" part of the GDB frame ID should usually be equivalent to
the DWARF-2 notion of a "call frame address".

-- 
Daniel Jacobowitz
CodeSourcery, LLC