PING^2 Re: [RFAv5 0/3] Convenience functions $_gdb_setting/$_gdb_setting_str

From: Philippe Waroquiers <philippe.waroquiers@skynet.be>

Ping ?
(attaching a patch rebased on master)
Thanks
Philippe

On Sun, 2019-09-29 at 17:28 +0200, Philippe Waroquiers wrote:
> Ping
> Thanks
> Philippe
> 
> On Sun, 2019-09-15 at 20:53 +0200, 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.
> > 
> > So, this patch series implements this.
> > 4 functions are provided:
> >   * $_gdb_setting_str returning a string value of the setting.
> >   * $_gdb_setting, returning an integer or string value of a setting,
> >     depending on the setting type.
> >     For integer/boolean/auto boolean settings, this is easier to use
> >     than the string version.
> >   * $_gdb_maint_setting, $_gdb_maint_setting_str : same as above, but
> >     for maintenance settings.
> > 
> > This is v5.
> > Compared to v4, it handles the comments of Pedro.
> > In particular, it tests the type of the function results.
> > 
> > Some notes:
> > In settings.exp show_setting, I have not added a check that RESET_VALUE
> > differs from the expected value: this means to add a specific reset_value
> > to a lot of show_setting calls.  As enough different values are verified,
> > this seems not necessary.
> > 
> > For what concerns ptype $_gdb_setting("something") always giving type int:
> > This is "normal".  For example, "ptype $_as_string(123)" similarly gives int.
> > 
> > The reason: ptype evalues the given expression, but in a way that avoids
> > side effects.  This then leads to eval_call in eval.c, that does:
> >   ...
> >   if (noside == EVAL_AVOID_SIDE_EFFECTS)
> >     {
> >       ...
> > 
> >       if (TYPE_CODE (ftype) == TYPE_CODE_INTERNAL_FUNCTION)
> > 	{
> > 	  /* We don't know anything about what the internal
> > 	     function might return, but we have to return
> > 	     something.  */
> > 	  return value_zero (builtin_type (exp->gdbarch)->builtin_int,
> > 			     not_lval);
> > 
> > and so any internal GDB function will always have the "type int".
> > Wondering if it would not be better to report an error such as
> > ("No type information for GDB functions") rather than lie.
> > 
> >
From 096d8adf6e9e1ab9a01174e94fd898b448d78341 Mon Sep 17 00:00:00 2001
From: Philippe Waroquiers <philippe.waroquiers@skynet.be>
Date: Sun, 28 Apr 2019 14:38:18 +0200
Subject: [PATCH 1/3] Implement convenience functions to examine GDB settings.

The new convenience functions $_gdb_setting and $_gdb_setting_str
provide access to the GDB settings in user-defined commands.
Similarly, $_gdb_maint_setting and $_gdb_maint_setting_str
provide access to the GDB maintenance settings.

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 doing such access via Python 'gdb.parameter' and/or
'gdb.execute("set somesetting tosomevalue"):
* 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 restore the original setting.

* Effectively, with the "gdb.parameter" python one liner, it is possible to do
  simple 'if' conditions, such as set and restore pagination.
  But 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 likely doable, but seems
  not easy with the above one liners.

So, in summary, the $_gdb_setting and $_gdb_setting_str avoids to have the
heterogeneous 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).

gdb/ChangeLog
2019-09-15  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

	* cli/cli-cmds.c (setting_cmd, value_from_setting)
	(gdb_setting_internal_fn, gdb_maint_setting_internal_fn)
	(str_value_from_setting, gdb_setting_str_internal_fn)
	(gdb_maint_setting_str_internal_fn): New functions.
	(_initialize_cli_cmds): Define the new convenience functions.
	* gdb/cli/cli-setshow.h (get_setshow_command_value_string): Constify.
	* gdb/cli/cli-setshow.c (get_setshow_command_value_string): Constify.
---
 gdb/cli/cli-cmds.c    | 232 ++++++++++++++++++++++++++++++++++++++++++
 gdb/cli/cli-setshow.c |   2 +-
 gdb/cli/cli-setshow.h |   2 +-
 3 files changed, 234 insertions(+), 2 deletions(-)

PING^2 Re: [RFAv5 0/3] Convenience functions $_gdb_setting/$_gdb_setting_str

Commit Message

Patch