Re: [RFAv3 0/3] Convenience functions $_gdb_setting/$_gdb_int_setting

[Philippe Waroquiers <philippe dot waroquiers at skynet dot be>]

On Mon, 2019-07-08 at 17:34 +0100, Pedro Alves wrote:
> Hi Philippe,
> 
> Some overall design comments below.
> 
> On 7/6/19 11:49 AM, Philippe Waroquiers wrote:
> > As part of the discussion of 'show | set may-call-functions [on|off]',
> > Eli suggested to have a way to access the GDB settings from
> > user defined commands.
> > 
> 
> As I had mentioned back then:
> 
>  https://sourceware.org/ml/gdb-patches/2019-04/msg00562.html
> 
> we can already access the settings via Python.  E.g. see it
> done here from a gdbinit script:
> 
>  https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00135.html
> 
> Copied here for convenience:
> 
>  python __gcc_prev_pagination=gdb.parameter("pagination")
>  set pagination off
>  ...
>  python if __gcc_prev_pagination: gdb.execute("set pagination on")
> 
> Given that, and the existence of the "with" command now for the
> common case, I'd like to at least see some mention/rationale/argument
> in the commit logs about why this is worth having/maintaining
> over just using gdb.parameter.

Here is some background about the rational:

The patch was developed following a comment of Eli about the
'set may-call-functions'. Eli said that user-defined functions
should have a way to change their behavior according to this setting.
Rather than have a specialized $_may_call_functions, this patch
implements a general way to access any GDB setting.

Compared to the above access via Python:
* The 'with' command is much better than the above python usage:
  if the user types C-c or an error happens between the set pagination off
  and the python "set pagination on", the above python 
  does not restory the original setting.

* Effectively, with the above python one liner, it is possible to do
  simple 'if' conditions, such as set and restore pagination.
  But as far as I can see, mixing the "python if" within canned
  sequence of commands is cumbersome for non trivial combinations.
  E.g. if several commands have to be done for a certain condition
  accessed from python, I guess something like will be needed:
     python if __some_setting: gdb.execute("some command")
     python if __some_setting: gdb.execute("some other command")
     python if __some_setting: gdb.execute("some different command")
  (without speaking about nested "if-s").

  With the convenience function:
     if $_gdb_setting("some_setting")
        some command
        some other command
        some different command
     end
  Integer settings (for example print elements) will also be more difficult
  to use.
  For example, a user defined function that scans and prints a linked list
  might want to use the value of "set print elements" to stop printing
  the linked list.
  Doing that by mixing python expression/if is I guess doable, but seems
  not easy with the above one liners.

So, in summary, the $_gdb_setting=$_gdb_int_setting avoids to have the
heterogenous mix of python and GDB commands in one single script
(and of course, it works even if python is not configured, but that
must be an unusual setup I guess).


> 
> BTW, did you look into how gdb.parameter is implemented, see if
> anything could be shared?
I quickly looked at the implementation of python gdb.parameter,
but could not find anything significant that can be shared.
Note that $_gdb_setting is (now) re-using the function
get_setshow_command_value_string that was developed for
the "with" command.

> 
> BTW², kind of unfortunate that Python used a different naming
> here (settings vs parameters).
> 
> > So, this patch series implements this.
> > 
> > 2 functions are provided:
> >   * $_gdb_setting that gives access to all settings, giving back a string value.
> >   * $_gdb_int_setting, giving access to boolean, auto-boolean and integers.
> >     This is easier to use for such types than the string version.
> 
> The naming of the functions kind of seems a bit reversed to me.  Off hand, I'd
> expect $_gdb_setting to give me the setting in its native type, and then
> something like $_gdb_setting_str to give me a string version/representation.
Probably my Ada background that pushes me to have strongly typed functions :).

I think it is easy to have $_gdb_setting returning 'int' (for types that can
be converted to integers) and strings for the others,
and have $_gdb_setting_str always returning a string.

> 
> Also, it seems like a design issue that settings that are unsigned
> internally get their values exposed as signed.
Not sure I understand the comment.
$_gdb_int_setting returns an integer value that is the same as what
the user can type.  If the user can type -1 (as a synonym for unlimited),
then $_gdb_int_setting returns -1, otherwise it will show 0 for unlimited.

> 
> I guess it could be even better if the setting's types were some new built-in
> types specific for the settings, and then if you wanted to get a string
> representation, you'd use '$_as_string($_gdb_setting(...))'.  (*)
Maybe I miss the idea: not too clear what this new built-in
'setting type' would bring, as the user will have in any case to convert
it to a 'basic' type  (e.g. int or string) to use it e.g. in an expression.
So, that seems significantly more work without clear gain.

> 
> (*) this made me wonder about a special $_python convenience function,
> which would take some python code as argument, and return a value, so you
> could write:
> 
>  if $_python(gdb.parameter ("pagination"))
>    ...
>  end
That would be a less cumbersome way to mix python expressions and canned
sequence of commands, but I am wondering if this mix is preferable
to the above convenience functions, as it implies the user has to
(at least somewhat) master both environments even for simple things.


Thanks

Philippe

> 
> etc.
> 
> > This is v3.
> > Compared to v1, it rebases to a recent master, and handles the comments
> > of Eli about the documentation.
> > 
> > (there was in fact no changes between v2 and v1, because I forgot to
> > commit the changes before sending the RFAv2 mail).
> 
> Thanks,
> Pedro Alves