]> git.ipfire.org Git - thirdparty/valgrind.git/commit
Allow the user to change a set of command line options during execution.
authorPhilippe Waroquiers <philippe.waroquiers@skynet.be>
Wed, 21 Aug 2019 12:33:39 +0000 (14:33 +0200)
committerPhilippe Waroquiers <philippe.waroquiers@skynet.be>
Sat, 31 Aug 2019 12:41:10 +0000 (14:41 +0200)
commit3a803036f719b048cb22630c530dbc012f7f53f9
tree8b40f217225bc81039b9ed6a4b413e4358143922
parentd2658f71c3d09034068bc6f7a115f44ce9535ad8
Allow the user to change a set of command line options during execution.

This patch changes the option parsing framework to allow a set of
core or tool (currently only memcheck) options to be changed dynamically.

Here is a summary of the new functionality (extracted from NEWS):
* It is now possible to dynamically change the value of many command
  line options while your program (or its children) are running under
  Valgrind.
  To have the list of dynamically changeable options, run
     valgrind --help-dyn-options
  You can change the options from the shell by using vgdb to launch
  the monitor command "v.clo <clo option>...".
  The same monitor command can be used from a gdb connected
  to the valgrind gdbserver.
  Your program can also change the dynamically changeable options using
  the client request VALGRIND_CLO_CHANGE(option).

Here is a brief description of the code changes.
* the command line options parsing macros are now checking a 'parsing' mode
  to decide if the given option must be handled or not.
  (more about the parsing mode below).

* the 'main' command option parsing code has been split in a function
  'process_option' that can be called now by:
     - early_process_cmd_line_options
        (looping over args, calling process_option in mode "Early")
     - main_process_cmd_line_options
        (looping over args, calling process_option in mode "Processing")
     - the new function VG_(process_dynamic_option) called from
       gdbserver or from VALGRIND_CLO_CHANGE (calling
        process_option in mode "Dynamic" or "Help")

* So, now, during startup, process_option is called twice for each arg:
   - once during Early phase
   - once during normal Processing
  Then process_option can then be called again during execution.

So, the parsing mode is defined so that the option parsing code
behaves differently (e.g. allows or not to handle the option)
depending on the mode.

// Command line option parsing happens in the following modes:
//   cloE : Early processing, used by coregrind m_main.c to parse the
//      command line  options that must be handled early on.
//   cloP : Processing,  used by coregrind and tools during startup, when
//      doing command line options Processing.
//   clodD : Dynamic, used to dynamically change options after startup.
//      A subset of the command line options can be changed dynamically
//      after startup.
//   cloH : Help, special mode to produce the list of dynamically changeable
//      options for --help-dyn-options.
typedef
   enum {
      cloE = 1,
      cloP = 2,
      cloD = 4,
      cloH = 8
   } Clo_Mode;

The option parsing macros in pub_tool_options.h have now all a new variant
*_CLOM with the mode(s) in which the given option is accepted.
The old variant is kept and calls the new variant with mode cloP.
The function VG_(check_clom) in the macro compares the current mode
with the modes allowed for the option, and returns True if qq_arg
should be further processed.

For example:

// String argument, eg. --foo=yes or --foo=no
   (VG_(check_clom)                                                     \
    (qq_mode, qq_arg, qq_option,                                        \
     VG_STREQN(VG_(strlen)(qq_option)+1, qq_arg, qq_option"=")) &&      \
    ({const HChar* val = &(qq_arg)[ VG_(strlen)(qq_option)+1 ];         \
      if      VG_STREQ(val, "yes") (qq_var) = True;                     \
      else if VG_STREQ(val, "no")  (qq_var) = False;                    \
      else VG_(fmsg_bad_option)(qq_arg, "Invalid boolean value '%s'"    \
                                " (should be 'yes' or 'no')\n", val);   \
      True; }))

   VG_BOOL_CLOM(cloP, qq_arg, qq_option, qq_var)

To make an option dynamically excutable, it is typically enough to replace
    VG_BOOL_CLO(...)
by
    VG_BOOL_CLOM(cloPD, ...)

For example:
-   else if VG_BOOL_CLO(arg, "--show-possibly-lost", tmp_show) {
+   else if VG_BOOL_CLOM(cloPD, arg, "--show-possibly-lost", tmp_show) {

cloPD means the option value is set/changed during the main command
Processing (P) and Dynamically during execution (D).

Note that the 'body/further processing' of a command is only executed when
the option is recognised and the current parsing mode is ok for this option.
29 files changed:
NEWS
coregrind/m_errormgr.c
coregrind/m_gdbserver/m_gdbserver.c
coregrind/m_gdbserver/server.c
coregrind/m_libcprint.c
coregrind/m_main.c
coregrind/m_options.c
coregrind/m_scheduler/scheduler.c
coregrind/m_signals.c
coregrind/pub_core_errormgr.h
coregrind/pub_core_libcprint.h
coregrind/pub_core_options.h
docs/xml/manual-core-adv.xml
docs/xml/manual-core.xml
exp-sgcheck/pc_common.c
gdbserver_tests/mchelp.stdoutB.exp
gdbserver_tests/mssnapshot.stderrB.exp
helgrind/hg_main.c
include/pub_tool_gdbserver.h
include/pub_tool_libcprint.h
include/pub_tool_options.h
include/valgrind.h
memcheck/mc_main.c
memcheck/tests/Makefile.am
memcheck/tests/nanoleak_dynsupp.stderr.exp [new file with mode: 0644]
memcheck/tests/nanoleak_dynsupp.vgtest [new file with mode: 0644]
memcheck/tests/nanoleak_supp.c
none/tests/cmdline1.stdout.exp
none/tests/cmdline2.stdout.exp