Re: variable objects and registers

[Nick Roberts <nickrob@snap.net.nz>]

 > >  > I've settled on -var-list. I don't think 'create' clarifies much,
 > >  > and this is not user command,
 > > 
 > > Except that it doesn't just list existing variable objects but "creates"
 > > new ones.
 > 
 > I fact, I'm not sure what duplicated
 > 
 > 	-var-list --locals 
 > 
 > should do. Create afresh, or just return already created?

Thats a fair point.  It should only create new variable objects if execution
enters a new block.  That makes -var-list a reasonable name.  In the manual I
should have said "...creates variable objects for the children if they do not
already exist.".

 > > The latter is "-stack-list-locals --make-varobjs" isn't it?  Or are you
 > > talking about variables declared within compound statements?
 > 
 > Both. -stack-list-locals --make-varobjs creates variable objects for all
 > variables in a function, including in nested blocks.

Well plain "-stack-list-locals just prints those that are in scope (as does
"info locals").  How does it differentiate between variable object for
expressions with the same name? (ISTR varobj.c hashes the name of the expression
to work out where to store it).

 > I think it might be good idea for you and I to go though Apple branch
 > grepping for all "APPLE LOCAL" markers so that we know everything they've
 > added.

Apple have made extensive changes.  I might look for specific changes if I'm
pointed towards them (as for the asynchronous event loop) but I'm not going
to look at all of it.

 > > The distinction I'm making is that var_* functions and variables are for
 > > use in MI and generally live in mi_cmd_var.c while varobj_* ones may be
 > > used by Insight and live in varobj.c
 > 
 > I don't think the difference between "var" and "varobj" in function name
 > communicates what you want, and I don't think such a coding guideline makes
 > sense for future.

Looking more closely the distinction doesn't seem to exist for variable names
which are often just var for struct varobj (presumably for brevity).  As long
as there are two separate files for variable objects (because Insight only
needs one, varobj.c), it seems a harmless and mildly useful guideline for
function names to me.



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