This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] Implement show | set can-call-inferior-functions [on|off]


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]