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

[Philippe Waroquiers <philippe dot waroquiers at skynet dot 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.
> > 
> >

Attachment: patch_ping.txt
Description: Text document