RFC: gdbglobals.[ch]

RFC: gdbglobals.[ch]

[Fernando Nasser]

I guess you are all aware of the problem we currently have with variables
being needed somewhere else and then becoming globals (or spinning off
global accessor functions).

This is hitting the user interfaces as they have facilities to set/show
some of these variables (see, for instance, the inferior_args case).

As per Andrew's request, I have wrote down a proposal based on a private
conversation we had so that we can see what people think about it.

Here it is:

GDB GLOBALS
===========

GDB "globals" allow gdblib information to be shared with other GDB components,
like the user interfaces or script languages.
It provides a standard way to access and share data.

Data will be registered by the provider and will have a symbolic "name"
so that other components interested in accessing it can use this name to
request access symbolically.

It will also have a "type", which will be (initially) one of:

enum var_types
  {
    /* "on" or "off".  *VAR is an integer which is nonzero for on,
       zero for off.  */
    var_boolean,

    /* "on" / "true" / "enable" or "off" / "false" / "disable" or
       "auto.  *VAR is an ``enum cmd_auto_boolean''.  NOTE: In general
       a custom show command will need to be implemented - one that
       for "auto" prints both the "auto" and the current auto-selected
       value. */
    var_auto_boolean,

    /* Unsigned Integer.  *VAR is an unsigned int.  The user can type 0
       to mean "unlimited", which is stored in *VAR as UINT_MAX.  */
    var_uinteger,

    /* Like var_uinteger but signed.  *VAR is an int.  The user can type 0
       to mean "unlimited", which is stored in *VAR as INT_MAX.  */
    var_integer,

    /* String which the user enters with escapes (e.g. the user types \n and
       it is a real newline in the stored string).
       *VAR is a malloc'd string, or NULL if the string is empty.  */
    var_string,

    /* String which stores what the user types verbatim.
       *VAR is a malloc'd string, or NULL if the string is empty.  */
    var_string_noescape,

    /* String which stores a filename.
       *VAR is a malloc'd string, or NULL if the string is empty.  */
    var_filename,

    /* ZeroableInteger.  *VAR is an int.  Like Unsigned Integer except
       that zero really means zero.  */
    var_zinteger,

    /* Enumerated type.  Can only have one of the specified values.  *VAR is a
       char pointer to the name of the element that we find.  */
    var_enum
  };

The libgdb module registering the global will provide the name, type and address
of the data.  It can also provide (optionally) a call back routine to be invoked
if the data is changed.  A handle is returned.

The GDB component trying to access the data will request it by name and provide
a call back routine (optional) to be invoked when the data changes.
It will receive, on success, a handle to be used when invoking the accessor routines.

Accessor routines will be provided to set or get the data.  Data shall only be accessed
through these functions, so proper notification is given to registered consumers.


Tentative API:

/* Register a global and optionally a callback. */

extern gdb_global_handle 
           gdb_global_register (char *name, enum var_types type, char *addr,
                                const char *enumlist[],
                                gdb_global_callback_ftype notify_me);

/* Get handle to access a global and optionally register callback. */

extern gdb_global_handle
           gdb_global_request (char *name, enum var_types type,
                               gdb_global_callback_ftype notify_me);

/* Obtain the current value of a global. */

extern gdb_global_rc
           gdb_global_get_value (gdb_global_handle global, char **cur_val);

/* Obtain all possible values for a var_enum global.
   Returns pointer to the NULL-terminated list of pointers to the values. */

extern gdb_global_rc
           gdb_global_get_enum_values (gdb_global_handle global, char **values[]);

/* Set a new value in a global and notify consumers. */

extern gdb_global_rc
           gdb_global_set_value (, char *new_val);

/* Replace the global value with a new implementation.  Notify consumers. */

extern gdb_global_rc
           gdb_global_replace (gdb_global_handle global, char *new_addr,
                               const char *enumlist[]);

/* Obtain the name, type and current value of a global given the handle. */

extern gdb_global_rc
           gdb_global_info (gdb_global_handle global,
                            char *name, enum var_types type, char **cur_val);

/* Obtain a list of all globals that match a regular expression,
   with name, type and current value. 
   Returns malloc'ed NULL-terminated list of handles. */

extern gdb_global_rc
           gdb_global_list (struct re_pattern_buffer *regex, gdb_global_handle **list);

/* Callback function type. */

typedef void (gdb_global_callback_ftype) (gdb_global_handle global,
                                          gdb_global_handle new_handle);
                                         


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

Re: RFC: gdbglobals.[ch]

[Eli Zaretskii]

> Date: Tue, 12 Dec 2000 14:49:12 -0500
> From: Fernando Nasser <fnasser@cygnus.com>
>
> enum var_types
>   {

Why is a `double' missing from this enum?

> /* Obtain the current value of a global. */
> 
> extern gdb_global_rc
>            gdb_global_get_value (gdb_global_handle global, char **cur_val);

Shouldn't the last argument be a "void **"?

> /* Set a new value in a global and notify consumers. */
> 
> extern gdb_global_rc
>            gdb_global_set_value (, char *new_val);

Something (a handle?) is missing here.

Re: RFC: gdbglobals.[ch]

[Fernando Nasser]

Thank you for your comments Eli.


Eli Zaretskii wrote:
> 
> > Date: Tue, 12 Dec 2000 14:49:12 -0500
> > From: Fernando Nasser <fnasser@cygnus.com>
> >
> > enum var_types
> >   {
> 
> Why is a `double' missing from this enum?
> 

Because I just used whatever we currently have in commands.h,
which implies we do not have any doubles yet settable with
set/show commands.

I had added a "(initially)" in my draft but I somehow took it off.



> > /* Obtain the current value of a global. */
> >
> > extern gdb_global_rc
> >            gdb_global_get_value (gdb_global_handle global, char **cur_val);
> 
> Shouldn't the last argument be a "void **"?
> 

I initially defined it as a void ** but then I realized out set/show
facility and the commands.h stuff use char **.

To minimize the conversion effort I thought of keeping it like it is now.

I wonder if this was not done this way due to some compatibility problem.
Maybe the reason no longer exists anyway.


> > /* Set a new value in a global and notify consumers. */
> >
> > extern gdb_global_rc
> >            gdb_global_set_value (, char *new_val);
> 
> Something (a handle?) is missing here.

Ops!  Thanks.  You are right, it is the handle.


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

Re: RFC: gdbglobals.[ch]

[Eli Zaretskii]

> Date: Wed, 13 Dec 2000 14:37:26 +0000
> From: Fernando Nasser <fnasser@cygnus.com>
> 
> > > /* Obtain the current value of a global. */
> > >
> > > extern gdb_global_rc
> > >            gdb_global_get_value (gdb_global_handle global, char **cur_val);
> > 
> > Shouldn't the last argument be a "void **"?
> 
> I initially defined it as a void ** but then I realized out set/show
> facility and the commands.h stuff use char **.
> 
> To minimize the conversion effort I thought of keeping it like it is now.
> 
> I wonder if this was not done this way due to some compatibility problem.
> Maybe the reason no longer exists anyway.

I suspect that was to pacify non-ANSI/non-ISO compilers.  Since we
don't support those anymore, I'd suggest to use void **.  I'm afraid
that a good ANSI compiler, and with the warning options we now use by
default, will bitch at char **.

Re: RFC: gdbglobals.[ch]

[Fernando Nasser]

Eli Zaretskii wrote:
> 
> > Date: Wed, 13 Dec 2000 14:37:26 +0000
> > From: Fernando Nasser <fnasser@cygnus.com>
> >
> > > > /* Obtain the current value of a global. */
> > > >
> > > > extern gdb_global_rc
> > > >            gdb_global_get_value (gdb_global_handle global, char **cur_val);
> > >
> > > Shouldn't the last argument be a "void **"?
> >
> > I initially defined it as a void ** but then I realized out set/show
> > facility and the commands.h stuff use char **.
> >
> > To minimize the conversion effort I thought of keeping it like it is now.
> >
> > I wonder if this was not done this way due to some compatibility problem.
> > Maybe the reason no longer exists anyway.
> 
> I suspect that was to pacify non-ANSI/non-ISO compilers.  Since we
> don't support those anymore, I'd suggest to use void **.  I'm afraid
> that a good ANSI compiler, and with the warning options we now use by
> default, will bitch at char **.

OK, I will change that in the final version.

Thanks.

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

Re: RFC: gdbglobals.[ch]

[J.T. Conklin]

>>>>> "Fernando" == Fernando Nasser <fnasser@cygnus.com> writes:
Fernando> I guess you are all aware of the problem we currently have
Fernando> with variables being needed somewhere else and then becoming
Fernando> globals (or spinning off global accessor functions).
Fernando>
Fernando> This is hitting the user interfaces as they have facilities
Fernando> to set/show some of these variables (see, for instance, the
Fernando> inferior_args case).
Fernando>
Fernando> As per Andrew's request, I have wrote down a proposal based
Fernando> on a private conversation we had so that we can see what
Fernando> people think about it.

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.

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.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: RFC: gdbglobals.[ch]

[Fernando Nasser]

"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