Re: Understanding GDB frames

[Ross Morley <ross at tensilica dot com>]

Jim Blandy wrote:

> Ross Morley <ross@tensilica.com> writes:
>  
>
> > Jim Blandy wrote:
> >    
> >
> > > After I'd sent my last post I realized that, of course, the "entry
> > > point PC" approach fails in the (I'd guess) more common case that the
> > > "return address PC" does not:
> > >
> > >   void foo (void) {}
> > >   main () { foo (); foo (); }
> > >
> > > Perhaps the best approach is to use both the return address and the
> > > entry point in the frame ID.  If either have changed, it's certainly a
> > > new frame.
> > >
> > >
> > >      
> > Well not quite certainly, eg.
> >
> >   void bar (void) {}
> >   void foo (void) { bar (); }
> >   main () { foo (); foo (); }
> >
> > But definitely an improvement that's easy to achieve.
> >    
>
> I don't follow.  Is there something here where a frame's return
> address and entry point change, but it's not a new frame?  I'm not
> claiming using both the return address and the entry point would
> eliminate false positives in frame_eq, just that it restricts false
> positives and does not introduce false negatives.
>
>  
I'm sorry, I misread your post. Your "certainly" is certainly right. :-)

We need to remember, though, that one goal is to minimize the overhead
for the MI front end of having to re-create varobjs. As we get better
at detecting a frame change (reduce false positives) we actually increase
the overhead for the FE because it then (to be correct) needs to recreate
its varobjs. We should think about solving that problem before we get too
much better at detecting frame changes.

Ross