[DTrace-devel] [oracle/dtrace-utils] 8368e0: cg, providers: refactor clearing probe arguments

[Kris Van Hees]

  Branch: refs/heads/devel
  Home:   https://github.com/oracle/dtrace-utils
  Commit: 8368e07a519bfcc1871b0bcf4a3d53d6913fef23
      https://github.com/oracle/dtrace-utils/commit/8368e07a519bfcc1871b0bcf4a3d53d6913fef23
  Author: Kris Van Hees <kris.van.hees at oracle.com>
  Date:   2026-01-16 (Fri, 16 Jan 2026)

  Changed paths:
    M libdtrace/dt_cg.c
    M libdtrace/dt_cg.h
    M libdtrace/dt_prov_cpc.c
    M libdtrace/dt_prov_dtrace.c
    M libdtrace/dt_prov_profile.c
    M libdtrace/dt_prov_sdt.c
    M libdtrace/dt_prov_syscall.c

  Log Message:
  -----------
  cg, providers: refactor clearing probe arguments

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


  Commit: 3813535e1a44a1257985d7f297b28d2473812c92
      https://github.com/oracle/dtrace-utils/commit/3813535e1a44a1257985d7f297b28d2473812c92
  Author: Kris Van Hees <kris.van.hees at oracle.com>
  Date:   2026-01-16 (Fri, 16 Jan 2026)

  Changed paths:
    M libdtrace/dt_bpf.c

  Log Message:
  -----------
  bpf: allocate the buffers BPF map to fit highest CPU id

Even when less than the possible number of CPUs are online, the 'buffers'
BPF map should be allocated based on the highest possible CPU id because
probe data is written to the bufer that corresponds to a given CPU id,
which could be part of non-sequential CPU id configurations.

The observed problem was on a system with 128 possible CPUs (0-127), but
only CPUs 0-7,100-107 were online.  The 'buffers' BPF map was created with
space to hold 16 trace data buffers (one for each online CPU), and since it
is an array map, this caused the trace buffers for CPUs 100-107 to fail to
allocate buffers, which in turn caused any trace data generated for those
CPUs never to get reported.  Since 'buffers' is an array map accessed by
CPU id, enough space must be allocated to accomodate the highest online
CPU id.

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


  Commit: 199436c2131b6ed452063ac4aa6325a00bbd59c5
      https://github.com/oracle/dtrace-utils/commit/199436c2131b6ed452063ac4aa6325a00bbd59c5
  Author: Kris Van Hees <kris.van.hees at oracle.com>
  Date:   2026-01-16 (Fri, 16 Jan 2026)

  Changed paths:
    M libdtrace/dt_options.c
    A test/unittest/options/err.version-pragma.d
    A test/unittest/options/err.version-pragma.r
    M test/unittest/options/err.version.d
    M test/unittest/options/err.version.r
    R test/unittest/options/tst.version.r
    R test/unittest/options/tst.version.sh
    R test/unittest/version/err.1.1.d
    R test/unittest/version/tst.1.0.d

  Log Message:
  -----------
  options: discontinue -xversion=V as a valid option

DTrace allowed setting a previous version to operate in compatibility
mode.  Unfortunately, it was not fully implemented.  Translators are
not really versioned, and if a translator uses an identifier that does
not exist in the version specified in -xversion=V, data structures end
up corrupted.

Since the usefulness of -xversion=V seems to be less than the effort
needed to rectify the implementation, we are no longer supporting this
option.

Tests added to ensure that the error is reported for -xversion=V and
when set using a pragma.  The former version tests have been removed
as they have become obsolete.

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


Compare: https://github.com/oracle/dtrace-utils/compare/f23700eb32d8...199436c2131b

To unsubscribe from these emails, change your notification settings at https://github.com/oracle/dtrace-utils/settings/notifications