Nick Roberts wrote:
>Maxim Grigoriev writes:
> > > It's worth pointing out that the 'PC' in a
frame ID isn't the current
> > > PC within the function. It's always the PC
of the function's entry
> > > point, so that stepping within a function
doesn't cause the frame ID
> > > to change. Usually it's a PC value returned
by 'frame_func_unwind',
> > > which takes care of calling
get_pc_function_start for you.
> >
> > We've been using a function return address instead
of
> > the PC of the function's entry, and it works just
fine.
>
>But does this explain why xt-gdb didn't detect the
variable objects coming back
>into scope when an i386 gdb did?
>
>
In this case it's because Xtensa uses the return address
rather than the
function entrypoint in the frame ID. Two calls from the same
caller have
different frame IDs. That's not the case in i386.
Technically the variable didn't come back into scope, a new
instance
of it was created. It's sometimes convenient to treat it as
if it came
back into scope.
Ross
> > The good part of our approach is it allowed to
expose some
> > problems with MI variable objects 
>
>Actually I think we've discussed this behaviour before
and done nothing about
>it.
>
>
>
|