[DTrace-devel] [oracle/dtrace-utils] cfd279: proc: convert to use standard SDT provider impleme...

Tue Mar 18 18:00:38 UTC 2025

  Branch: refs/heads/devel
  Home:   https://github.com/oracle/dtrace-utils
  Commit: cfd279acd47237ac58883724c3a8dc93aa4e362d
      https://github.com/oracle/dtrace-utils/commit/cfd279acd47237ac58883724c3a8dc93aa4e362d
  Author: Kris Van Hees <kris.van.hees at oracle.com>
  Date:   2025-03-18 (Tue, 18 Mar 2025)

  Changed paths:
    M libdtrace/dt_prov_proc.c

  Log Message:
  -----------
  proc: convert to use standard SDT provider implementation

The proc provider was the first SDT-based provider implememted in DTrace
based on BPF, and therefore handled the enabling of probes with custom
code.  When the other SDT-based providers (sched, ...) were implemented,
a generic SDT-framework was developed.

Update the proc provider to use the generic SDT-framework.

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

  Commit: b71bbf7a94acbcba96eac10a23f2d2864b6b03d6
      https://github.com/oracle/dtrace-utils/commit/b71bbf7a94acbcba96eac10a23f2d2864b6b03d6
  Author: Kris Van Hees <kris.van.hees at oracle.com>
  Date:   2025-03-18 (Tue, 18 Mar 2025)

  Changed paths:
    M libdtrace/dt_prov_sched.c

  Log Message:
  -----------
  sched: clean up unnecessary includes and functions

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

  Commit: d9dac3fc40e1789e0d43f3e91d6a4cad2f287b68
      https://github.com/oracle/dtrace-utils/commit/d9dac3fc40e1789e0d43f3e91d6a4cad2f287b68
  Author: Kris Van Hees <kris.van.hees at oracle.com>
  Date:   2025-03-18 (Tue, 18 Mar 2025)

  Changed paths:
    M libdtrace/dt_prov_rawfbt.c

  Log Message:
  -----------
  rawfbt: perform lookup on true symbol names

When encountering a <sym>.<suffix> symbol, a symbol lookup was done for
<sym> instead of <sym>.<suffix> under the assumption that names with .
in them were not listed in kallsyms.  But that is not true.

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

  Commit: c1b7d2016f7eb555a4f5d15eb5f6aa081b174643
      https://github.com/oracle/dtrace-utils/commit/c1b7d2016f7eb555a4f5d15eb5f6aa081b174643
  Author: Kris Van Hees <kris.van.hees at oracle.com>
  Date:   2025-03-18 (Tue, 18 Mar 2025)

  Changed paths:
    M libdtrace/dt_module.c

  Log Message:
  -----------
  ksyms: make symbol name filters less picky

Some symbols were being filtered out even though they represent symbols
that can actually be probed.

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

  Commit: a53f33fb5acf287376bc527fd7eacf991110538c
      https://github.com/oracle/dtrace-utils/commit/a53f33fb5acf287376bc527fd7eacf991110538c
  Author: Kris Van Hees <kris.van.hees at oracle.com>
  Date:   2025-03-18 (Tue, 18 Mar 2025)

  Changed paths:
    M libdtrace/dt_symtab.c
    M libdtrace/dt_symtab.h

  Log Message:
  -----------
  symtab: add support for 'traceable' flag and add dt_symbol_by_name_next()

The traceable flag can be set on symbols to indicate that the symbol can
be traced using kernel facilities.

The traceable flag can be set on a symtab to indicte that its symbols
have traceable flags associated with them.

When the same symbol exists in multiple modules, dt_symbol_by_name()
returns reference to the first one.  The dt_symbol_by_name_next()
function is used to walk through the rest of the list (if any).

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

  Commit: 87e199975769f57387ce9a0cbebb653574c578f4
      https://github.com/oracle/dtrace-utils/commit/87e199975769f57387ce9a0cbebb653574c578f4
  Author: Kris Van Hees <kris.van.hees at oracle.com>
  Date:   2025-03-18 (Tue, 18 Mar 2025)

  Changed paths:
    M libdtrace/dt_module.c
    M libdtrace/dt_module.h
    M libdtrace/dt_prov_fbt.c

  Log Message:
  -----------
  fbt: performance improvements

Up until now, FBT probes were registered for every symbol that was
listed as traceable.  Most tracing sessions do not use most or even
any of these, and the process of registering them all was quite
slow.

Going forward, FBT probes are registered on demand.

If any FBT probes are to be registered, the first will incur the
cost of reading the entire list of traceable symbols.  Any further
FBT probe registration will be able to be satisfied based on that
initial processing.  The performance improvement is therefore quite
significant for tracing sessions that do not trigger any FBT probe
registration, and if FBT probes are used, the improvement is still
quite noticable because only the probes that are actually needed
get registered.

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

  Commit: 2f40aa3dbcf4c0697230d41dcfb0d64e4448b3ad
      https://github.com/oracle/dtrace-utils/commit/2f40aa3dbcf4c0697230d41dcfb0d64e4448b3ad
  Author: Kris Van Hees <kris.van.hees at oracle.com>
  Date:   2025-03-18 (Tue, 18 Mar 2025)

  Changed paths:
    M libdtrace/dt_prov_rawfbt.c

  Log Message:
  -----------
  rawfbt: performance improvements

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

  Commit: 0b7c5a6327dc0f3a4f6e1bed401e17442a931d52
      https://github.com/oracle/dtrace-utils/commit/0b7c5a6327dc0f3a4f6e1bed401e17442a931d52
  Author: Kris Van Hees <kris.van.hees at oracle.com>
  Date:   2025-03-18 (Tue, 18 Mar 2025)

  Changed paths:
    M libdtrace/Build
    M libdtrace/dt_prov_fbt.c
    R libdtrace/dt_prov_rawfbt.c

  Log Message:
  -----------
  fbt, rawfbt: consolidate code to avoid duplication

After optimizing both fbt and rawfbt providers, the resulting code has
a significant amount of duplication.  The rawfbt provider can now be
defined in terms of the kprobe-based fbt provider functions.

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

  Commit: 4bb6327a2de6611e91095b5e6177285f4bb00f0d
      https://github.com/oracle/dtrace-utils/commit/4bb6327a2de6611e91095b5e6177285f4bb00f0d
  Author: Kris Van Hees <kris.van.hees at oracle.com>
  Date:   2025-03-18 (Tue, 18 Mar 2025)

  Changed paths:
    M libdtrace/dt_bpf.c
    M libdtrace/dt_bpf.h
    M libdtrace/dt_error.c
    M libdtrace/dt_prov_uprobe.c

  Log Message:
  -----------
  error: report probe name on failed enabling error

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

  Commit: ad68224b00187f7345284e92ba79b6b99540b8bb
      https://github.com/oracle/dtrace-utils/commit/ad68224b00187f7345284e92ba79b6b99540b8bb
  Author: Kris Van Hees <kris.van.hees at oracle.com>
  Date:   2025-03-18 (Tue, 18 Mar 2025)

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

  Log Message:
  -----------
  bpf: fix have_attach_type() detection

There are kernel versions that support the BPF_TRACE_FENTRY attach type
at program load, but do not support opening the attachment point (a
kernel symbol by BTF id) as a raw tracepoint.  The cause is that the
support for fentry as a raw tracepoint was initially only implemented
on x86_64.

We now test both program load *and* opening the raw tracepoint to know
if BPF_TRACE_FENTRY as attach type is supported.

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

Compare: https://github.com/oracle/dtrace-utils/compare/39a5e0a8866b...ad68224b0018

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