Re: Understanding GDB frames

[Maxim Grigoriev <maxim@tensilica.com>]

> But does this explain why xt-gdb didn't detect the
> variable objects coming back
> into scope when an i386 gdb did?

Yes, it does. Thanks to Ross, who already explained it in the previous email on this thread.

> Actually I think we've discussed this behavior before
> and done nothing about it.

I suggest we improve gdb documentation in the way that, when
we don't have time to describe things properly, we at
least put a reference to a corresponding GDB-mailing-list
discussion.

-- Maxim


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