[DTrace-devel] [oracle/dtrace-utils] 5372c3: work: run under valgrind

Nick Alcock noreply at github.com
Thu Sep 9 04:06:06 PDT 2021


  Branch: refs/heads/nix/valgrind
  Home:   https://github.com/oracle/dtrace-utils
  Commit: 5372c396df5b479c7b2d57532b6002740cd90ca6
      https://github.com/oracle/dtrace-utils/commit/5372c396df5b479c7b2d57532b6002740cd90ca6
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2021-09-07 (Tue, 07 Sep 2021)

  Changed paths:
    M dtrace.spec
    M libdtrace/dt_work.c

  Log Message:
  -----------
  work: run under valgrind

Running BEGIN/END probes under valgrind failed because these probes work
by dropping uprobes on DTrace itself, and uprobes fail if the uprobed
process is being valgrinded: the breakpoint instruction inserted by
uprobes is translated into VEX IR and then emulated by valgrind, and the
emulation is located at a different address than the address originally
used by the kernel: so the kernel has no idea it was a uprobe, and
passes the breakpoint through to dtrace itself, killing it with a
SIGTRAP.

The solution is to use the bizarrely-named VALGRIND_NON_SIMD_CALL0
request to call the probes when valgrind is in use.  This asks valgrind
to invoke a function on the real CPU rather than the emulated one, which
invokes it from the right address, so the kernel spots the uprobe for
what it is. VALGRIND_NON_SIMD_CALL* has harsh and barely-documented
requirements on what it can be used to call, but our probe functions are
entirely empty, so we can be pretty sure it'll always work for us.

Signed-off-by: Nick Alcock <nick.alcock at oracle.com>
Orabug: 32760574





More information about the DTrace-devel mailing list