[DTrace-devel] [oracle/dtrace-utils] 3753d6: uapi headers: include <sys/dtrace_types> as needed

euloh noreply at github.com
Thu Oct 27 21:24:44 UTC 2022


  Branch: refs/heads/dev
  Home:   https://github.com/oracle/dtrace-utils
  Commit: 3753d677444576eb7bf409586ac9a43c1a874286
      https://github.com/oracle/dtrace-utils/commit/3753d677444576eb7bf409586ac9a43c1a874286
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2022-10-27 (Thu, 27 Oct 2022)

  Changed paths:
    M include/dtrace/actions_defines.h
    M include/dtrace/dof_defines.h
    M test/Build
    A test/internals/headers/tst.header-endianness.sh

  Log Message:
  -----------
  uapi headers: include <sys/dtrace_types> as needed

This is needed for _LITTLE_ENDIAN and _BIG_ENDIAN.

Add a new internals test to identify this class of failure: add a
tag 'uninstalled' which is disabled in the installed tree to prevent it
from being executed as part of the installed testsuite (since it is not
particularly useful outside the installed set, and making it work in
both places would be complicated and annoying).

Signed-off-by: Nick Alcock <nick.alcock at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>


  Commit: 79a4245beb82997bf63cb1ca9ea9140e725b7e41
      https://github.com/oracle/dtrace-utils/commit/79a4245beb82997bf63cb1ca9ea9140e725b7e41
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2022-10-27 (Thu, 27 Oct 2022)

  Changed paths:
    M libdtrace/dt_link.c

  Log Message:
  -----------
  dt_link: finish backing out varint, fixing dt_link-generated object files

For a while now, linking dtrace -G-generated object files has been
saying

/usr/bin/ld: .../build/test-triggers--usdt-tst-special.o: error adding symbols: no error

This is more than slightly confusing.  For starters, collect2 is
corrupting the error message: the actual error is

/usr/bin/ld: .../build/test-triggers--usdt-tst-special.o: error adding symbols: file format not recognized

This is not much more helpful.  The actual cause is in
elf_link_add_object_symbols:

      name = bfd_elf_string_from_elf_section (abfd, hdr->sh_link,
					      isym->st_name);

where the symbol name comes out as NULL.  This is because we are hitting
a sanity check in bfd_elf_string_from_elf_section:

      /* PR 24273: The string section's contents may have already
	 been loaded elsewhere, eg because a corrupt file has the
	 string section index in the ELF header pointing at a group
	 section.  So be paranoid, and test that the last byte of
	 the section is zero.  */
      if (hdr->sh_size == 0 || hdr->contents[hdr->sh_size - 1] != 0)
	return NULL;

This paranoia has won out! We are generating string tables with
hdr->sh_size one too small, pointing at the last byte of the last
string.

The cause is somewhat gross.  dt_link.c:process_obj computes the length
of the new strtab it's constructing by adding all the symbol names to a
dt_strtab, asking it for its size, subtracting one for the \0 at the
first byte, and then throwing the strtab away and directly editing the
strtab in the object file, using the strtab it generated earlier only
for its size.  Doing things in two stages like this is a bit risky: it's
riskier yet because it's using a dt_strtab, which is not a model of an
ELF strtab at all but rather of a DTrace string table.  No harm, they're
the same: except that when varints landed the format of a string
naturally changed to gain an extra length byte at the start. The size
computation was changed to subtract two bytes rather than one (itself
buggy: *every string in the strtab* had an extra byte on the front of
it, so the wrong number of bytes was being subtracted and the resulting
sh_size was too large).  But when the varint code was backed out (in
29e3f422 "Remove the string length prefix"), this size computation was
not changed back, leading to a sh_size that is one byte too low,
triggering this failure.

Signed-off-by: Nick Alcock <nick.alcock at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>


  Commit: 943fb84ab31c70ff01a0121960378a1138d7d60e
      https://github.com/oracle/dtrace-utils/commit/943fb84ab31c70ff01a0121960378a1138d7d60e
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2022-10-27 (Thu, 27 Oct 2022)

  Changed paths:
    M libdtrace/dt_bpf.c
    M libdtrace/dt_cg.c

  Log Message:
  -----------
  providers: allow providers with no trampoline

Such providers can be enabled just like any other, but generate no code.

Meant for use by providers like pid which have some probes without
trampolines (but which enable other probes which do contain trampolines
that execute on their behalf).  Both such probes need enabling because
we want to ensure their names are interned, etc: we only want to avoid
trying to execute their trampoline when there is none.

Signed-off-by: Nick Alcock <nick.alcock at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>


  Commit: d2ea2f7d1354439676b53b46b268097bccd9fc03
      https://github.com/oracle/dtrace-utils/commit/d2ea2f7d1354439676b53b46b268097bccd9fc03
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2022-10-27 (Thu, 27 Oct 2022)

  Changed paths:
    M Makeconfig

  Log Message:
  -----------
  build: add header+symbol checking

The new check-header-symbol-rule Makeconfig rule allows checking to see
whether a header #inclusion plus a symbol usage plus a given -l library
usage compiles and links successfully.  It's analogous to the Autoconf
AC_TRY_COMPILE macro.

Signed-off-by: Nick Alcock <nick.alcock at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>


  Commit: 64a37fb8b8e0252bd38e831abc1ab38287cf90c8
      https://github.com/oracle/dtrace-utils/commit/64a37fb8b8e0252bd38e831abc1ab38287cf90c8
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2022-10-27 (Thu, 27 Oct 2022)

  Changed paths:
    M Makeconfig
    M include/port.h
    M libport/Build
    A libport/close_range.c
    A libport/daemonize.c

  Log Message:
  -----------
  port: add daemonization support code

This assists in writing reliable daemons, providing a close_range() that
works on older glibc/kernel combinations, and a daemonize() which
provides a synchronization pipe down which error messages can also be
sent, so that errors occurring after daemonize() is called but before
the daemon is fully working can be reliably reported.

(This uses the check-header-symbol-rule feature just added to let us
verify not only that close_range() is present in libc, but that it's
present in the headers and has the right prototype.  The history of
close_range is a right tangled mess... as usual with glibc features,
linking isn't required to work unless the header is included too, so
we test both at once.)

Signed-off-by: Nick Alcock <nick.alcock at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>


  Commit: e46168272e8574f4cf75978356d7973a0c09ffc3
      https://github.com/oracle/dtrace-utils/commit/e46168272e8574f4cf75978356d7973a0c09ffc3
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2022-10-27 (Thu, 27 Oct 2022)

  Changed paths:
    M include/sys/sol_procfs.h
    M libproc/Pcontrol.h
    M libproc/Psymtab.c
    M libproc/libproc.h

  Log Message:
  -----------
  libproc: add Pinode_to_file_map()

This lets you rapidly look up the prmap_file_t that corresponds to a
(dev, ino) pair in a given process's mappings.  This is useful when
dealing with uprobes, which work on an *inode* basis, not a process
basis or even a mapping basis: we can use this to see whether a process
we are otherwise interested in has ownership of a given (dev, ino)
mapping rapidly, and what the details of the mapping are.

Do it with a hash table rather than linear iteration because these days
it is getting increasingly common to have processes with a great many
mappings.  Chromium has 1638 mappings on my system, of which 411 are
file-backed, but the real mapping king these days is Emacs with native
compilation, which maps every Lisp file as a separate shared object:
3618 mappings, of which 3135 are file-backed!

While we're at it, rename the (Psymtab.c-private) Pprmap_file_by_name
to Pfilename_to_file_map, so that all prmap_file_t functions have
consistent names (and names less terrible than Pprmap_file_by_name).

Signed-off-by: Nick Alcock <nick.alcock at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>


  Commit: 164fe6f04bbd18c77906e7d127785da19890f14a
      https://github.com/oracle/dtrace-utils/commit/164fe6f04bbd18c77906e7d127785da19890f14a
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2022-10-27 (Thu, 27 Oct 2022)

  Changed paths:
    M libproc/Psymtab.c

  Log Message:
  -----------
  libproc: fix double-free on error path

Signed-off-by: Nick Alcock <nick.alcock at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>


  Commit: ec5254b2fff2327b0c2c61d208dd47052a8fef5d
      https://github.com/oracle/dtrace-utils/commit/ec5254b2fff2327b0c2c61d208dd47052a8fef5d
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2022-10-27 (Thu, 27 Oct 2022)

  Changed paths:
    A libcommon/Build
    A libcommon/GNUmakefile
    A libcommon/dt_list.c
    A libcommon/dt_list.h
    M libdtrace/Build
    R libdtrace/dt_list.c
    R libdtrace/dt_list.h
    M libproc/Build
    M libproc/Pcontrol.c
    M test/triggers/Build
    M test/utils/Build

  Log Message:
  -----------
  usdt: common infrastructure

USDT will include a daemon that implements a CUSE device that programs
containing USDT probes issue ioctl()s to.  This daemon needs to create
uprobes, and this needs to use libproc to extract information about the
processes (like mapping addresses, etc).  This is something the rest of
DTrace can already do: so split out infrastructure needed by libproc and
infrastructure needed to create uprobes into a new libcommon (static)
library that the daemon can use.  Make tiny adjustments to libproc and
triggers that use it so that libproc can stand independent of libdtrace
(it was very nearly there already: only one debugging statement change
and a move of dt_list into the common library is needed).

A future commit will adjust DTrace to use this library to create uprobes
too.

Signed-off-by: Nick Alcock <nick.alcock at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>


  Commit: 5b43ff17f839195a29cadf255a947514d15aa478
      https://github.com/oracle/dtrace-utils/commit/5b43ff17f839195a29cadf255a947514d15aa478
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2022-10-27 (Thu, 27 Oct 2022)

  Changed paths:
    A include/tracefs.h
    M libcommon/Build
    A libcommon/uprobes.c
    A libcommon/uprobes.h
    M libdtrace/dt_prov_dtrace.c
    M libdtrace/dt_provider.h

  Log Message:
  -----------
  libcommon: move uprobes creation into the common library

This commit adds functions in the libcommon library to create uprobes
given a pid and address, create uprobes given more detailed info (a
(dev, ino, addr) triplet, a spec for the uprobe_events file, and a
DTrace probe name), and compute a spec. We also provide
encoding/decoding functions to allow the uprobe to contain the DTrace
probe name as part of its args even though DTrace probes can contain
characters that are not allowed in uprobe names or arg names, and even
though probe arg names must be unique while DTrace probe name components
need not be.

The DTrace provider is rejigged to use this code to generate the
BEGIN/END/ERROR probes, to make sure this code works.

Signed-off-by: Nick Alcock <nick.alcock at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>


  Commit: 75ed17e6822ab7bae6827b19ed2364d1bc9159cd
      https://github.com/oracle/dtrace-utils/commit/75ed17e6822ab7bae6827b19ed2364d1bc9159cd
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2022-10-27 (Thu, 27 Oct 2022)

  Changed paths:
    M Makeoptions
    M libcommon/Build
    A libcommon/dof_parser.c
    A libcommon/dof_parser.h
    A libcommon/dof_parser_host.c

  Log Message:
  -----------
  libcommon: DOF parsing

This commit adds a DOF parser, derived from DTrace v1 but simplified.
The parser is intended to run in a strict-mode seccomp jail, and does no
I/O except via pre-provided file descriptors.  The host side should do
I/O using the functions in dof_parser_host.h.

The seccomp parser child returns output as a stream of dof_parsed_t
records, which are variable-length records with an early size member
(the reader code in dof_parser_host.c takes care of reading the right
amount of data).  Errors are returned as PIT_ERR records in this stream,
or signified by a simple crash (in which case the invoker can simply
restart it).

The parser has a notably noisy debugging mechanism which can be turned
on via make dof_dbg=yes (it is separate from make debugging=yes because
it makes the daemon emit lots of stuff on stderr, which you're unlikely
to want unless you're actually debugging USDT itself).

Signed-off-by: Nick Alcock <nick.alcock at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>


  Commit: a79ec6805ecc675354d5cf2994843d027e67881f
      https://github.com/oracle/dtrace-utils/commit/a79ec6805ecc675354d5cf2994843d027e67881f
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2022-10-27 (Thu, 27 Oct 2022)

  Changed paths:
    M GNUmakefile
    M Makeconfig
    A dtprobed/60-dtprobed.rules
    A dtprobed/Build
    A dtprobed/GNUmakefile
    A dtprobed/dtprobed.c
    A dtprobed/dtprobed.service
    A dtprobed/dtrace-usdt.target
    A dtprobed/rpl_fuse_log.c
    A dtprobed/rpl_fuse_log.h
    M dtrace.spec
    M runtest.sh

  Log Message:
  -----------
  usdt: daemon

This commit adds a daemon, "dtprobed", which usually runs at boot
(monitored by systemd, if possible), providing /dev/dtrace/helper using
CUSE, accepting DOF from processes doing the usual DTrace ioctl()s to
that device, and using infrastructure in prior commits in this series to
pass the DOF to a child jailed with seccomp() for parsing, and accepting
structures containing parsed results back, then emitting uprobes from
these results before allowing the ioctl()ing.  The uprobes created have
stereotyped names and argument lists that include an encoded
representation of the name of the corresponding DTrace USDT probe.  (The
name also contains the address and a number of other things, so that
probes that appear in multiple places in a process still work.)

(The CUSE device is an "unrestricted ioctl" device, which restricts
dtprobed to running only as root, because the ioctl has to pull data --
the DOF -- out of arbitrary places in the client memory according to the
passed-in structure. Since you need to be root to create uprobes at all
this is not any kind of restriction.)

Extra complexity is provided by changes to libfuse.  Recent (> 2018)
libfuse has a nice logging interface, which if available means that
libfuse will log FUSE-side problems into syslog or anywhere else of your
choosing: we emit into syslog if -d or -F (debug, foreground) are not
specified and systemd is not in use (if systemd is in use, we never
daemonize at all).  But older libfuse does not provide this, and
unfortunately OL8 (but not OL7!) has such an older libfuse.  So we add a
compatibility wrapper providing a minimal reimplementation of the
logging interface if built against such an old libfuse.  The wrapper is
named like the header and source file implementing the real thing in
FUSE itself, but prepended with rpl_ to avoid the possibility of
dependencies on header file ordering when the new FUSE code is present.

Testing-wise, in installed mode the running dtprobed daemon is used, but
in in-source-tree mode runtest.sh kicks off a new dtprobed emitting to a
local device file named /dev/dtrace/test-$pid, and uses a new
testing-only environment variable to force drti.c to emit its ioctl()s
to that temporary device.  So in-tree testing always tests the actual
dtprobed in the tree (with any bugfixes), not the system copy.

Signed-off-by: Nick Alcock <nick.alcock at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>


  Commit: 2f069320c3d421e24b8197505650a0ca862e7ef3
      https://github.com/oracle/dtrace-utils/commit/2f069320c3d421e24b8197505650a0ca862e7ef3
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2022-10-27 (Thu, 27 Oct 2022)

  Changed paths:
    M libdtrace/drti.c

  Log Message:
  -----------
  drti: use /proc/self/maps

This works in conjunction with PID namespaces where using getpid() does
not.

Signed-off-by: Nick Alcock <nick.alcock at oracle.com>
Reviewed-by: Eugene Loh <eugene.loh at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>


  Commit: 7c37a88221d1168f7a874fcfd6b106dc6c1bb935
      https://github.com/oracle/dtrace-utils/commit/7c37a88221d1168f7a874fcfd6b106dc6c1bb935
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2022-10-27 (Thu, 27 Oct 2022)

  Changed paths:
    M libdtrace/dt_prov_fbt.c
    M libdtrace/dt_prov_syscall.c
    M libdtrace/dt_provider_tp.c

  Log Message:
  -----------
  fbt, syscall: use getline(), not fgets()

This lets us drop lots of code to handle too-long lines.  (Done for
consistency with the pid provider, which will do the same thing in a
subsequent commit.)

Signed-off-by: Nick Alcock <nick.alcock at oracle.com>
Reviewed-by: Eugene Loh <eugene.loh at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>


  Commit: b552dbe3624256f1fbb97d08bdf8765f6c523aac
      https://github.com/oracle/dtrace-utils/commit/b552dbe3624256f1fbb97d08bdf8765f6c523aac
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2022-10-27 (Thu, 27 Oct 2022)

  Changed paths:
    M libdtrace/dt_dof.c

  Log Message:
  -----------
  dof: don't emit providers with no probes

Without this, you end up with DOF with a lot of zero-probe providers
in.  This not only wastes space but causes the DOF to fail validation
(arguably unnecessarily, but why waste the space in the first place?)

Signed-off-by: Nick Alcock <nick.alcock at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>


  Commit: a28e369c6fcacb324e1fdcf87fd78b621daa488f
      https://github.com/oracle/dtrace-utils/commit/a28e369c6fcacb324e1fdcf87fd78b621daa488f
  Author: Kris Van Hees <kris.van.hees at oracle.com>
  Date:   2022-10-27 (Thu, 27 Oct 2022)

  Changed paths:
    M libcommon/uprobes.c
    M libcommon/uprobes.h

  Log Message:
  -----------
  libcommon: add uprobe_name() and uprobe_delete()

Signed-off-by: Kris Van Hees <kris.van.hees at oracle.com>
Reviewed-by: Nick Alcock <nick.alcock at oracle.com>


  Commit: 95ac5e2496d13200ff72109f7dbccfc3359fb0c6
      https://github.com/oracle/dtrace-utils/commit/95ac5e2496d13200ff72109f7dbccfc3359fb0c6
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2022-10-27 (Thu, 27 Oct 2022)

  Changed paths:
    M include/dtrace/pid.h
    M libdtrace/Build
    M libdtrace/dt_cg.c
    M libdtrace/dt_cg.h
    M libdtrace/dt_impl.h
    M libdtrace/dt_open.c
    M libdtrace/dt_pid.c
    M libdtrace/dt_pid.h
    M libdtrace/dt_prov_fbt.c
    R libdtrace/dt_prov_pid.c
    M libdtrace/dt_prov_sdt.c
    A libdtrace/dt_prov_uprobe.c
    M libdtrace/dt_provider.h

  Log Message:
  -----------
  usdt: DTrace userspace side

This is implemented almost entirely along with the pid provider, which is
reassuringly similar to how it was done in the in-kernel days. They're
really very closely-related beasts, and the same uprobe-based code can
handle both easily enough.  To reflect this, dt_prov_pid.c is renamed to
dt_prov_uprobe.c.

This does several things that are sufficiently intertwined that putting
them in one commit seems most readable:

 - implements USDT probe discovery, ripping out a lot of old ioctl stuff
   and obsolete code handling stuff like structure-copying thunks in the
   Solaris C library and a bunch of obsolete functions around DOF
   acquisition (keeping one which might well be revived in the next
   phase), and adding dt_pid_create_usdt_probes, which scans the
   systemwide uprobe list and creates DTrace-side USDT probes (and their
   associated underlying uprobe-based probes) for any that are relevant
   (see below), using an sscanf-based parser: the uprobe naming scheme
   was designed so that it works with the limitations of such parsers.
   Thanks to the %m conversion specifier there is no risk of buffer
   overrunning if the name components are unexpectedly long.

   Right now this can only create probes for specific processes (those
   named on the command line in probe names, as usual), but in future
   it'll grow the ability to make probes for everything dtprobed has
   spotted probes for.  Because it is driven by the systemwide uprobe
   list, it can create probes for processes that started before DTrace
   did, just like the old in-kernel model.

 - rejigs the pid provider support in dt_prov_uprobe.c (formerly
   dt_prov_pid.c) to use the new uprobe_create mechanism to make pid
   probes, with names consistent with uprobes created by dtprobed for
   USDT probes; the uprobes have names like dt_pid/[pr]_$dev_$ino_$addr.
   USDT probes pass their name components down as encoded uprobe
   arguments, viz:

   p:dt_pid/dt_2d_231d_7fbe933165fd /tmp/runtest.17112/usdt-dlclose1.123064.9010/livelib.so:0x15fd Ptest_prov=\1 Mlivelib__2eso=\2 Fgo=\3 Ngo=\4

   (The [PMFN] prefix is added and stripped off automatically by the
   name en/decoder, and makes sure that no two "args" have the same
   name, even if the probe component is the same, as above.)

 - provides provide_usdt_probe to be called at USDT probe discovery
   time to create USDT probes and their underlying uprobe-based probes.
   The creation of the underlying uprobe-based probes is split off into
   a new funtion create_underlying that is also used for pid probes.
   Probe naming is designed to ensure that USDT probes and pid probes
   that are created at the same offset are associated with the same
   underlying probe.

   The struct dt_uprobe attached to the underlying probe gains a device
   number (which it should always have had) and keeps track of the
   underlying uprobe name from create_uprobe or USDT probe discovery
   and remembers whether or not DTrace created it (if dtprobed created
   it, dtrace must not delete it).

   USDT probes can be associated with more than one underlying probe
   (if the probe appears repeatedly in a program).  Repeated calls to
   provide_usdt_probe for the same probe description but with different
   offsets will cause the USDT probe to be chained into the appropriate
   underlying probes (creating them as needed).

 - enabling gets a little more complex.  We intern both the overlying
   (pid and USDT) probe *and* the associated underlying probe in the
   enablings list (by getting ->enable for the pid/USDT probe to walk
   its list of underlying probes and enable all of them), and to also
   add itself to the enablings list.

 - Trampoline generation has to adapt to this, but also has to use a
   less kludgy way of figuring out the pids the trampoline applies to:
   rather than parsing the name apart on the spot, we ask dt_pid, which
   already has code to *properly* parse apart both pid and usdt names
   and extract the pid from them.

 - stack arg handling needs a bit of a tweak.  USDT probes can take a
   set of arguments that and are implemented as a fake function call.
   The underlying uprobe is placed right after the argument setup and
   therefore should be retrieved without applying PT_REGS_ARGSTKBASE
   for platforms on which PT_REGS_ARGSTKBASE > 0.  The underlying
   probe gets the PP_IS_FUNCALL flag set to indicate this.

Signed-off-by: Nick Alcock <nick.alcock at oracle.com>
Signed-off-by: Kris Van Hees <kris.van.hees at oracle.com>
Reviewed-by: Nick Alcock <nick.alcock at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>


  Commit: 7ad418c47c7e500dfd2a92c99d50a044c3213da5
      https://github.com/oracle/dtrace-utils/commit/7ad418c47c7e500dfd2a92c99d50a044c3213da5
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2022-10-27 (Thu, 27 Oct 2022)

  Changed paths:
    M test/triggers/Build
    M test/unittest/pid/tst.provregex3.sh
    A test/unittest/usdt/tst.args-alt.aarch64.x
    M test/unittest/usdt/tst.args-alt.d
    M test/unittest/usdt/tst.args.d
    M test/unittest/usdt/tst.dlclose1.sh
    M test/unittest/usdt/tst.dlclose2.sh
    M test/unittest/usdt/tst.dlclose3.sh
    R test/unittest/usdt/tst.dlclose3.x
    M test/unittest/usdt/tst.eliminate.sh
    M test/unittest/usdt/tst.enable.d
    M test/unittest/usdt/tst.enable_and.d
    M test/unittest/usdt/tst.enable_and_2.d
    M test/unittest/usdt/tst.enable_or.d
    M test/unittest/usdt/tst.enable_or_2.d
    M test/unittest/usdt/tst.enable_return.d
    M test/unittest/usdt/tst.enable_stmt.d
    M test/unittest/usdt/tst.enabled.sh
    M test/unittest/usdt/tst.enabled2.sh
    M test/unittest/usdt/tst.entryreturn.sh
    M test/unittest/usdt/tst.fork.sh
    M test/unittest/usdt/tst.guess32.sh
    M test/unittest/usdt/tst.guess64.sh
    A test/unittest/usdt/tst.lingering.r
    A test/unittest/usdt/tst.lingering.sh
    M test/unittest/usdt/tst.multiple.sh
    M test/unittest/usdt/tst.reeval.sh
    M test/unittest/usdt/tst.static.sh
    M test/unittest/usdt/tst.static2.sh
    M test/unittest/usdt/tst.tailcall.d

  Log Message:
  -----------
  usdt: testsuite updates

A lot of tests can be enabled now, but a lot are still XFAIL: anything
that relies on is-enabled probes, systemwide probing, globbing of USDT
probe names, or args which are non-integral are guaranteed broken.

We add one new test to make sure that you can run a probe-containing
program and then repeatedly probe it from multiple dtraces in turn
without them messing up each others' probes in any way: the probes
linger from one dtrace to the next.  (Doing it from multiple dtraces in
*parallel* may well not work yet, as no specific code has been written
to make it work: that's planned for the next phase.)

Signed-off-by: Nick Alcock <nick.alcock at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>


  Commit: eddac94d22dea7a5165771f77c5f154e3ce3e0c4
      https://github.com/oracle/dtrace-utils/commit/eddac94d22dea7a5165771f77c5f154e3ce3e0c4
  Author: Eugene Loh <eugene.loh at oracle.com>
  Date:   2022-10-27 (Thu, 27 Oct 2022)

  Changed paths:
    M runtest.sh

  Log Message:
  -----------
  test: Signal an error if trigger does not exist

The behavior had been to ignore the trigger silently, leading to
mystifying outcomes.

Clean up a few other minor issues in runtest.sh.

Signed-off-by: Eugene Loh <eugene.loh at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>


  Commit: ec61b196c516403b3ded4c2677b67be66a4489dd
      https://github.com/oracle/dtrace-utils/commit/ec61b196c516403b3ded4c2677b67be66a4489dd
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2022-10-27 (Thu, 27 Oct 2022)

  Changed paths:
    M libdtrace/dt_pid.c

  Log Message:
  -----------
  pid: drop more Solaris-specific bug workarounds

We definitely don't have any old binaries that exhibit a problem only
observed on old versions of Solaris lacking modern ELF constructors.

Signed-off-by: Nick Alcock <nick.alcock at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>


  Commit: bbf2e42edd42223830aa7c33335c5817c14cb7b0
      https://github.com/oracle/dtrace-utils/commit/bbf2e42edd42223830aa7c33335c5817c14cb7b0
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2022-10-27 (Thu, 27 Oct 2022)

  Changed paths:
    M test/unittest/pid/tst.probefunc.d
    M test/unittest/pid/tst.weak1.d
    M test/unittest/pid/tst.weak2.d

  Log Message:
  -----------
  pid: a few more tests are now passing

These all depended on probefunc etc working.

Signed-off-by: Nick Alcock <nick.alcock at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>


  Commit: 22786c90f76f7e4bd7307c122aac3f278978fc36
      https://github.com/oracle/dtrace-utils/commit/22786c90f76f7e4bd7307c122aac3f278978fc36
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2022-10-27 (Thu, 27 Oct 2022)

  Changed paths:
    M libproc/Psymtab.c

  Log Message:
  -----------
  libproc: add the dev/ino pair to the mapping debug printout

This helps correlation with usdt probes, which are filtered out (really,
filtered in) by the dev/ino.

Signed-off-by: Nick Alcock <nick.alcock at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>


  Commit: 182688e33c22728f9c65e55d4422ddf1b459328c
      https://github.com/oracle/dtrace-utils/commit/182688e33c22728f9c65e55d4422ddf1b459328c
  Author: Kris Van Hees <kris.van.hees at oracle.com>
  Date:   2022-10-27 (Thu, 27 Oct 2022)

  Changed paths:
    M libdtrace/dt_parser.c

  Log Message:
  -----------
  String constants should be marked as DT_NF_DPTR

Although string constants are represented using a scalar offset into the
string constant table, the generated BPF code uses actual pointers into
the string constant table.  They are therefore pointers to DTrace-managed
storage (DT_NF_DPTR).

Signed-off-by: Kris Van Hees <kris.van.hees at oracle.com>
Reviewed-by: Eugene Loh <eugene.loh at oracle.com>


  Commit: 0236a08fead014896b7730c7716ed1843f041f37
      https://github.com/oracle/dtrace-utils/commit/0236a08fead014896b7730c7716ed1843f041f37
  Author: Kris Van Hees <kris.van.hees at oracle.com>
  Date:   2022-10-27 (Thu, 27 Oct 2022)

  Changed paths:
    M libdtrace/dt_parser.c
    A test/unittest/codegen/tst.execname-idx.d

  Log Message:
  -----------
  Ensure that 'execname' is not marked DPTR

The 'execname' builtin variable is a notable exception to REF-type
variables being DTrace-managed pointers.  It is a pointer into the
task_struct and therefore needs to be explicitly excluded from the
DPTR marking of variable nodes.

Signed-off-by: Kris Van Hees <kris.van.hees at oracle.com>
Reviewed-by: Eugene Loh <eugene.loh at oracle.com>


  Commit: 6d5cf4fb21f9d9938cc2d45bd8837270dd61da8f
      https://github.com/oracle/dtrace-utils/commit/6d5cf4fb21f9d9938cc2d45bd8837270dd61da8f
  Author: Kris Van Hees <kris.van.hees at oracle.com>
  Date:   2022-10-27 (Thu, 27 Oct 2022)

  Changed paths:
    M bpf/strcmp.S
    M libdtrace/dt_cg.c
    M test/unittest/builtinvar/tst.execname.d
    A test/unittest/codegen/tst.execname-cmp-bvar_lhs.d
    A test/unittest/codegen/tst.execname-cmp-bvar_rhs.d
    A test/unittest/codegen/tst.execname-cmp-const_lhs.d
    A test/unittest/codegen/tst.execname-cmp-const_rhs.d
    A test/unittest/codegen/tst.kernel_str-cmp-bvar_lhs.d
    A test/unittest/codegen/tst.kernel_str-cmp-bvar_rhs.d
    A test/unittest/codegen/tst.kernel_str-cmp-const_lhs.d
    A test/unittest/codegen/tst.kernel_str-cmp-const_rhs.d

  Log Message:
  -----------
  String args to dt_strcmp() need to be copied if not DPTR

The dt_strcmp() implementation makes use of indirect load instructions
to retrieve characters from either string argument.  That only works for
DTrace-managed storage pointers.  So, any argument that is not marked
DT_NF_DPTR must be copied into a tstring before the indirect loads are
done.

Signed-off-by: Kris Van Hees <kris.van.hees at oracle.com>
Reviewed-by: Eugene Loh <eugene.loh at oracle.com>


  Commit: 7ae3960b933ab3a8be9c67022865d4ec0c21ef18
      https://github.com/oracle/dtrace-utils/commit/7ae3960b933ab3a8be9c67022865d4ec0c21ef18
  Author: Kris Van Hees <kris.van.hees at oracle.com>
  Date:   2022-10-27 (Thu, 27 Oct 2022)

  Changed paths:
    A test/unittest/operators/tst.str_comparison-basic-with-NULL.d
    M test/unittest/operators/tst.str_comparison-basic.d

  Log Message:
  -----------
  test: split tst.str_comparison-basic.d into with and without NULL testing

Since NULL strings are not supported yet, the tst.str_comparison-basic.d
test is failing even though the non-NULL case should PASS without any
problem.  The test is now written as two tests: one that exercises the
case of NULL strings and one that does not.

Signed-off-by: Kris Van Hees <kris.van.hees at oracle.com>
Reviewed-by: Eugene Loh <eugene.loh at oracle.com>


  Commit: 9bd2fafda39fa9a1e3a91d017f2a6c6fe370ef27
      https://github.com/oracle/dtrace-utils/commit/9bd2fafda39fa9a1e3a91d017f2a6c6fe370ef27
  Author: Eugene Loh <eugene.loh at oracle.com>
  Date:   2022-10-27 (Thu, 27 Oct 2022)

  Changed paths:
    M libdtrace/dt_cg.c
    M libdtrace/dt_consume.c
    M test/unittest/tracemem/tst.init_task.d
    M test/unittest/types/tst.complex.d

  Log Message:
  -----------
  Error out on unrecognized actions

Note that this patch causes a few spuriously passing tests now
to fail.  So, they must be marked XFAIL.

One odd test is tst.clearavg2.d.  It was already marked XFAIL,
with the message made even more specific in patch fb264ec9 ("test:
Annotate tests that require missing features"), indicting clear().
But the test had actually started passing a few patches earlier,
in f256db8f ("Implement setopt()"), when the consumer was modified
to skip over unrecognized DTRACEACT_LIBACT records.  So, the test
had started to XPASS, an indication of its leniency.  With the
current patch, that test now correctly XFAILs:  its behavior is
now in line with its XFAIL.

Signed-off-by: Eugene Loh <eugene.loh at oracle.com>


  Commit: a6b2dcd80920f5cc03c6ae0b3c9b1802471cb98a
      https://github.com/oracle/dtrace-utils/commit/a6b2dcd80920f5cc03c6ae0b3c9b1802471cb98a
  Author: Eugene Loh <eugene.loh at oracle.com>
  Date:   2022-10-27 (Thu, 27 Oct 2022)

  Changed paths:
    M test/unittest/consumer/tst.symbols.c

  Log Message:
  -----------
  test: Speed up check for modname-symname duplicates

When we check "lookup by name", a mismatch is allowed if there are
duplicates with the same modname and symname.  So, we must be able
to detect when such duplicates occur.  We were using a linear search.

Add a quick sort by modname/symname and then initialize a field
"is_duplicate" to speed up detection of duplicates.

Signed-off-by: Eugene Loh <eugene.loh at oracle.com>


  Commit: 750a0691bda5c9443ebf0317a972afba94c63419
      https://github.com/oracle/dtrace-utils/commit/750a0691bda5c9443ebf0317a972afba94c63419
  Author: Eugene Loh <eugene.loh at oracle.com>
  Date:   2022-10-27 (Thu, 27 Oct 2022)

  Changed paths:
    M libdtrace/dt_module.c
    M test/unittest/consumer/tst.symbols.c

  Log Message:
  -----------
  Ignore module name __builtin__kprobes in kallmodsyms

Signed-off-by: Eugene Loh <eugene.loh at oracle.com>


Compare: https://github.com/oracle/dtrace-utils/compare/b3bed150a838...750a0691bda5



More information about the DTrace-devel mailing list