public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Philippe Waroquiers <philippe.waroquiers@skynet.be>
To: Eli Zaretskii <eliz@gnu.org>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFA] Implement show | set can-call-inferior-functions [on|off]
Date: Wed, 24 Apr 2019 21:25:00 -0000	[thread overview]
Message-ID: <1556141127.22002.9.camel@skynet.be> (raw)
In-Reply-To: <83sgu73nde.fsf@gnu.org>

On Wed, 2019-04-24 at 09:53 +0300, Eli Zaretskii wrote:
> > From: Philippe Waroquiers <philippe.waroquiers@skynet.be>
> > Cc: Philippe Waroquiers <philippe.waroquiers@skynet.be>
> > Date: Tue, 23 Apr 2019 23:58:26 +0200
> > 
> > Inferior function calls are powerful but might lead to undesired
> > results such as crashes when calling nested functions (frequently
> > used in particular in Ada).
> > 
> > This implements a GDB setting to disable calling inferior functions.
> 
> Thanks, I think this is useful functionality.
> 
> However, I question the wisdom of erroring out when an attempt is made
> to call inferior functions when that's disabled.  If this inferior
> call is part of some script, the script will error out at that point,
> which might not be what the user wants.  Erroring out is justified
> when the inferior function was called interactively, though.  Can we
> come up with something more useful for the scripting use case?  Like
> perhaps 'call' should display a warning and do nothing, 'print' should
> just display a warning, and otherwise the inferior would always return
> zero?  Or maybe this should be subject to some additional knob?

Generally, returning 0 (or whatever value) can then later on 
cause problems in a script.
For example, evaluating some function calls sometimes imply to first
call malloc in the inferior.  When can-call-inferior-functions is off,
returning 0 (or whatever) from malloc will then cause further problems
(such as a SEGV).

So, it looks to me that just forbidding function calls when set to "off'
is on the safe side (which is the objective of this setting when debugging
things you do not want to see crash or impact with inferior function calls).
Then, the user can always decide to temporarily change the setting
if desired, once the error message is visible.


I will do the suggested doc changes for the v2 of the patch,

Thanks

Philippe

> 
> > +set can-call-inferior-functions [on|off]
> > +show can-call-inferior-functions
> > +  Control whether GDB is allowed to do inferior function calls.
> > +  Inferior function calls are e.g. needed to evaluate and print
> > +  some expressions.  Such inferior function calls can have undesired
> > +  side effects.  It is now possible to forbid such inferior function
> > +  calls.
> > +  By default, GDB is allowed to do inferior function calls.
> 
> I think this should tell what happens if the function is called when
> inferior calls are not allowed.
> 
> > +@item set can-call-inferior-functions
> > +@kindex set can-call-inferior-functions
> > +@cindex disabling inferior function calls.
> 
> Index entries should not end with a period.
> 
> Also, I think an additional index entry here will be useful:
> 
>   @cindex inferior function calls, disabling
> 
> > +  add_setshow_boolean_cmd ("can-call-inferior-functions", no_class,
> > +			   &can_call_inferior_functions_p, _("\
> > +Set debugger's willingness to call inferior functions."), _("\
> > +Show debugger's willingness to call inferior functions."), _("\
> > +To call an inferior function, GDB has to temporarily modify the state\n\
> > +of the inferior.  This has potentially undesired side effects.\n\
> > +Also, having GDB calling nested functions is likely to be erroneous\n\
> > +and may even crash the program being debugged.\n\
> > +You can avoid such hazards by forbidding GDB to do inferior functions calls.\n\
> > +The default is to allow inferior function calls."),
> 
> I think this doc string is too detailed, you in effect copied here
> everything that we have in the manual, which is too much.  I suggest
> to leave out the rationale for disabling the inferior calls, and
> describe just the effects.  I do think this should say what happens
> with calls when they are disallowed.
> 
> Thanks, the documentation parts are OK once the above nits are taken
> care of.

  reply	other threads:[~2019-04-24 21:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-23 21:58 Philippe Waroquiers
2019-04-24  6:53 ` Eli Zaretskii
2019-04-24 21:25   ` Philippe Waroquiers [this message]
2019-04-25  6:12     ` Eli Zaretskii
2019-04-25 13:15       ` Tom Tromey
2019-04-25 19:44         ` Pedro Alves
2019-04-25 17:17 ` Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1556141127.22002.9.camel@skynet.be \
    --to=philippe.waroquiers@skynet.be \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).