Re: [PATCH] -stack-info-frame/-stack-list-frames

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

 > >  > Does that window shows:
 > >  > 
 > >  > 1. Value of variable named XXX in the frame where that variable was
 > >  > added to the window?
 > >  > 2. Value of variable named XXX in the current frame
 > >  > 3. Something else?
 > > 
 > > It doesn't really matter how it was created.
 > 
 > Of course it does, because for 2 (which are those floating varobjs), the
 > concept of frame varobj belongs is fairly moot.

Floating varobjs are evaluated in the selected frame and that's the (changing)
frame to which it belongs.
 
 > >  > Well, for other frames I know what they are used for.
 > > 
 > > (by frames you mean fields?)
 > 
 > Yes.
 >  
 > > Really?  In the output of -stack-list-frames what are the pc address field
 > > for the outer frames used for?
 > 
 > It's there so that you can know where you function is called from, in case
 > the caller is assembler and there's no other information about location.

I mean it's not interesting to see the pc addresses for all the frames in the
call stack simultaneously.  Only the pc address of the selected frame is really
of interest.

 >...
 > Yes, stack surely grows in the other directions on other architectures. But
 > that's probably not the main issue. What is the case when a user wants to
 > know which frame a variable having address XXX belongs to? If that variable
 > is varobj, GUI probably already recorded the association between varobj and
 > frame and is in position to show that directly.

Gdb knows with which frame the varobj is associated but two frames might
have the same variable name, and with recursion they might have the same
procedure name.  Then the user could only work out which was which (if he
forgets when they were created) by comparing the frame addresses with the
memory locations of the variable.

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