Re: RFC: gdbglobals.[ch]

[Fernando Nasser <fnasser at cygnus dot com>]

"J.T. Conklin" wrote:
> 
> Some things that are currently set/show variables would be convient to
> access from GDB scripts.  It appears that this proposal would compound
> that mistake by having yet another set of variables that cannot be
> accessed by GDB's scripting language.
> 

I agree that all the script languages should be able to use the $ variables for
use in expressions and such.  The MI provides this access already, and 
corresponding gdblib calls should also be available.  But  we are talking
about something else here.  Se, for instance, the "inferior_args" thread.   

We are not keeping the set/show variables, which are just variables
(exactly of the same types as the proposed gdbglobals) that have their
addresses exported to the CLI by a function call to the CLI (like add_set_cmd).
We also share other variables by making them globals and turning gdb into a maze.

We are just generalizing the mechanism to *reduce* the ways of doing things. 
The idea is that all set/show variables turn into gdbglobals, as well as all
other global variables.


> Why not make these regular GDB $ variables?  Then alternate scripting
> languages and user interfaces would only need one mechanism to access
> GDB variables instead of the two (or three, if this proposal is
> adopted) used today.
> 
> One problem would be ensuring a clean namespace so that user's scripts
> wouldn't break when new variables are exported from GDB.  I think this
> is solvable, and would result in a more coherent GDB/scripting language/
> UI layering.
> 

Using the gdb convenience ($) variables would be considerably slower as we would
have to search the symbolic space at each use.  Not to mention the type conversion.
Some of the variables we are talking about are used frequently and repeatedly.

Also, some of the values shared may not mean to be accessible by users
(the set/show ones are, but we have other globals).  Making them a $ variable
we would be exposing them to any user.

The gdbglobals also have some special types that can make handling things like
a set of possible values easier.  And we can add more types if necessary.
Compare this with the untyped $ variables...



I think the main reason not to use GDB convenience variables to substitute globals
is that we are talking about two different levels of abstraction.  The gdbglobals is
at the implementation level, while the convenience variables are at the use level.





-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9