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

[Christophe LYON <christophe.lyon@st.com>]

> > 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?

Thanks,

Christophe.