Re: Questions about MI variable objects

[Nick Roberts <nickrob at snap dot net dot nz>]

 > So, if Emacs wants displays to grey out when the frame disappears,
 > does it ever expect those expressions to become ungrey again?  After
 > all, that frame is gone forever.  Under what conditions should the
 > display become ungrey?

If the frame_id matches again.

 > >  > 4) If the user lets control run to 'foo' again, so the stack now looks
 > >  >    like:
 > >  > 
 > >  >        main -> bar (10) -> foo (9)
 > >  > 
 > >  >    what should happen to the display of 'x'?  (I'd say it should show
 > >  >    '9'.)
 > >
 > > That's what Emacs currently does and what the default GDB behaviour gives,
 > > although Daniel J doesn't seem to think it's useful.
 > 
 > Actually, I don't believe you.  :)  Would you humor me and try this
 > out?

My mistake, I read too quickly.  I was thinking it was going straight back into
foo, having just come out.  (I don't know why - ypu were quite clear.)

 > - Start with the program I posted.
 > - Set a breakpoint on foo.
 > - Run to the third hit (that is, foo (0))
 > - Display 'x'.
 > - finish three times, so that we're back in main.  We all agree the
 >   display should be 'greyed' out at this point.
 > - continue to the next hit of foo.
 > 
 > When I do this with what I assume are the corresponding MI commands,
 > the varobj I made for x in foo (0) is still out of scope.
 > 
 > If I continue again, I happen to get a frame whose address matches the
 > original foo (0) address, and the varobj comes back in scope, but this
 > is, again, a spurious frame ID match.  It happens only because the
 > frames sizes on the stack happen to line up.  The compiler could
 > generate different, correct, code and the varobj behavior would stop
 > working.

I have tried in the past to do something similar but could never get them to
line up.  (I tried to get two functions use the same amount of stack as
one function.)

 > So, at the moment, your displays based on '*'-frame varobjs ungrey at
 > times that appear reasonable in simple test programs, but are actually
 > dependent on flukes of your compiler's stack management.
 > 
 > Setting aside MI and GDB and varobjs, from your users' point of view,
 > when should that display come alive again?

When the function and stack trace matches again.  I generally use GDB in Emacs
just to debug GDB and Emacs (yeah, I know, it's all a bit circular) and there
the the frame_id only seems match again under these conditions

However I can't really speak for others, as, currently, there aren't many
people using GDB in Emacs 22.

 > >  > If there's some general agreement on how these ought to behave (not
 > >  > necessarily my guesses, just any agreement) then maybe we could make
 > >  > MI varobjs match that behavior, so that each GUI variable display
 > >  > could be backed by exactly one varobj, and GDB's reports on changes to
 > >  > the varobj's state would correspond closely to changes in the GUI's
 > >  > display.  Varobjs exist to help GUIs, and GDB shouldn't be making GUIs
 > >  > jump through hoops to get the behavior they want.
 > >
 > > I'm not sure how you intend to change GDB's behaviour but I think it should
 > > provide options rather than define the policy.
 > 
 > MI is a protocol; I don't want to break backwards compatibility.  But
 > there's no point in retaining backwards compatibility with a bug ---
 > when that bug's behavior is unpredictable.

Well, you call it a fluke when it works, but I would call it an (unlucky) fluke
when it fails.  My view is unacceptable, of course, when delivering to
customers.

 > > I don't really follow.  Can you give an real example where frame IDs
 > > collide?
 > 
 > Well, since it depends on the stack management code the compiler
 > emits, it's compiler-specific.  But on a Fedora Core 6 x86 machine:

Sure.  Sorry, I should have followed through your first example.

-- 
Nick                                           http://www.inet.net.nz/~nickrob