Re: Understanding GDB frames

[Ross Morley <ross@tensilica.com>]

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