This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Handling the 'next' command on a variable-length bundles target
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