public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
* [RFAv5 0/3] Convenience functions $_gdb_setting/$_gdb_setting_str
@ 2019-09-15 18:53 Philippe Waroquiers
  2019-09-15 18:53 ` [RFAv5 1/3] Implement convenience functions to examine GDB settings Philippe Waroquiers
                   ` (4 more replies)
  0 siblings, 5 replies; 10+ messages in thread
From: Philippe Waroquiers @ 2019-09-15 18:53 UTC (permalink / raw)
  To: gdb-patches

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.


^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2019-10-30 19:48 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-15 18:53 [RFAv5 0/3] Convenience functions $_gdb_setting/$_gdb_setting_str Philippe Waroquiers
2019-09-15 18:53 ` [RFAv5 1/3] Implement convenience functions to examine GDB settings Philippe Waroquiers
2019-10-30 19:43   ` Pedro Alves
2019-09-15 18:53 ` [RFAv5 2/3] Test the convenience functions $_gdb_setting and $_gdb_int_setting Philippe Waroquiers
2019-10-30 19:44   ` Pedro Alves
2019-09-15 18:53 ` [RFAv5 3/3] NEWS and documentation for " Philippe Waroquiers
2019-10-30 19:48   ` Pedro Alves
2019-09-29 15:28 ` PING Re: [RFAv5 0/3] Convenience functions $_gdb_setting/$_gdb_setting_str Philippe Waroquiers
2019-10-20 10:25   ` PING^2 " Philippe Waroquiers
2019-10-30 19:39 ` Pedro Alves

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).