[DTrace-devel] [oracle/dtrace-utils] ace34e: test: Allow duplicate usym/umod/uaddr if for diffe...
Kris Van Hees
noreply at github.com
Thu May 1 14:56:34 UTC 2025
Branch: refs/heads/devel
Home: https://github.com/oracle/dtrace-utils
Commit: ace34e708e409d28e9b6ff7fe22fe7a2043632be
https://github.com/oracle/dtrace-utils/commit/ace34e708e409d28e9b6ff7fe22fe7a2043632be
Author: Eugene Loh <eugene.loh at oracle.com>
Date: 2025-04-24 (Thu, 24 Apr 2025)
Changed paths:
M test/unittest/profile-n/tst.ufunc.sh
M test/unittest/profile-n/tst.umod.sh
M test/unittest/profile-n/tst.usym.sh
Log Message:
-----------
test: Allow duplicate usym/umod/uaddr if for different pids
In 83da884cbdc5 ("Preface usym/umod/uaddr with pid"), a bug was fixed
in which addresses in the same module (or function) might be mapped to
multiple agg entries. This fix helped the associated tests run much
more successfully. Nonetheless, tests would sometimes still fail.
Another problem is that the tests themselves were overly narrow. It
is fine for a module (or function) to appear multiple times in the
aggregation output... if those entries correspond to different pids.
Further, odd behaviors can result for some of the processes running on
a system.
Change the tests to add a "pid" agg key. Filter on only a few, select
pids. Distinguish agg entries by pid.
There are still occasional time outs observed with these tests,
presumably because the tick-2s probe is not firing (when profile-1234hz
is running).
Signed-off-by: Eugene Loh <eugene.loh at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>
Commit: 0f9a7221de5990013c63e936802e6f7e568b7300
https://github.com/oracle/dtrace-utils/commit/0f9a7221de5990013c63e936802e6f7e568b7300
Author: Eugene Loh <eugene.loh at oracle.com>
Date: 2025-04-24 (Thu, 24 Apr 2025)
Changed paths:
A test/unittest/usdt/skip_arm_uek6.x
A test/unittest/usdt/tst.argmap-typed-partial.aarch64.x
A test/unittest/usdt/tst.argmap-typed.aarch64.x
A test/unittest/usdt/tst.multiprov-dupprobe-fire.aarch64.x
A test/unittest/usdt/tst.multiprov-dupprobe-shlibs.aarch64.x
A test/unittest/usdt/tst.multiprovider-fire.aarch64.x
Log Message:
-----------
test: Expect USDT argmap to fail on ARM on older kernels
Signed-off-by: Eugene Loh <eugene.loh at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>
Commit: 5b442e6989b7b28ab5884295011504f2d1242079
https://github.com/oracle/dtrace-utils/commit/5b442e6989b7b28ab5884295011504f2d1242079
Author: Eugene Loh <eugene.loh at oracle.com>
Date: 2025-04-24 (Thu, 24 Apr 2025)
Changed paths:
M include/dtrace/metadesc.h
Log Message:
-----------
Remove orphaned dtrace_recdesc_t component dtrd_uarg
Signed-off-by: Eugene Loh <eugene.loh at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>
Commit: 49740f58e997afddb693798eaed53c3545dec63a
https://github.com/oracle/dtrace-utils/commit/49740f58e997afddb693798eaed53c3545dec63a
Author: Eugene Loh <eugene.loh at oracle.com>
Date: 2025-04-24 (Thu, 24 Apr 2025)
Changed paths:
M libdtrace/dt_prov_sched.c
M test/unittest/sched/tst.lv-dequeue.r
M test/unittest/sched/tst.lv-enqueue.r
Log Message:
-----------
Fix arg3 for sched enqueue and dequeue probes
For sched enqueue and dequeue probes, arg3 should be an int
for enqueue and not exist for dequeue. In the code it was
the other way around. Fix this and the associated tests.
The trampoline was already set up to get this argument correct.
Signed-off-by: Eugene Loh <eugene.loh at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>
Commit: 824f4788d58cb5f131d24da236967200030ff357
https://github.com/oracle/dtrace-utils/commit/824f4788d58cb5f131d24da236967200030ff357
Author: Eugene Loh <eugene.loh at oracle.com>
Date: 2025-04-24 (Thu, 24 Apr 2025)
Changed paths:
M bpf/get_agg.c
M bpf/get_bvar.c
M libdtrace/dt_bpf.c
M libdtrace/dt_cg.c
M libdtrace/dt_prov_lockstat.c
M libdtrace/dt_prov_sched.c
M libdtrace/dt_work.c
M test/unittest/sched/tst.enqueue.d
Log Message:
-----------
Clean up sched provider trampoline FIXMEs
The sched provider trampoline for enqueue and dequeue probes had
pending FIXMEs for providing a cpuinfo_t* for the cpu associated
with the run queue. Implement the missing code.
Since the cpu associated with the run queue might be different from
the cpu where we are running, it becomes necessary to access the
cpuinfo for some random cpu. With Linux 5.18, there is a BPF
helper function map_lookup_percpu_elem() that allows such lookups
on per-cpu arrays. To support older kernels, however, we change
the cpuinfo BPF map from per-cpu to global. Also, it is a hash
table rather than an array in case cpus are not numbered consecutively.
Signed-off-by: Eugene Loh <eugene.loh at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>
Commit: bef8fcab7f11db014abc767a7c76008ad1eedc0c
https://github.com/oracle/dtrace-utils/commit/bef8fcab7f11db014abc767a7c76008ad1eedc0c
Author: Eugene Loh <eugene.loh at oracle.com>
Date: 2025-04-24 (Thu, 24 Apr 2025)
Changed paths:
M test/unittest/cpc/tst.branches.sh
M test/unittest/cpc/tst.instructions.sh
Log Message:
-----------
test: Get cpc expected branches and instructions counts from perf
For a number of the cpc tests, we get expected counts from perf.
For branches and instructions, however, we can determine the
expected counts more directly since there is one branch and a
fixed number of instructions per iteration. Thus, we can derive
an expected cpc counts simply by knowing the number of iterations.
For some compilers, however, there is apparently some loop unrolling
even at low, default levels of optimization.
So, revert to the perf count to estimate the expected cpc count
even for the branches and instructions tests.
Signed-off-by: Eugene Loh <eugene.loh at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>
Commit: ff3eae5aa8337dcf38c79cbfb2b437da27163831
https://github.com/oracle/dtrace-utils/commit/ff3eae5aa8337dcf38c79cbfb2b437da27163831
Author: Eugene Loh <eugene.loh at oracle.com>
Date: 2025-04-24 (Thu, 24 Apr 2025)
Changed paths:
R test/unittest/lockstat/tst.lockstat.r
Log Message:
-----------
test: Remove orphaned tst.lockstat.r
In commit ded09d05a ("test: rework main lockstat test"), a lockstat
test was renamed. Its .r results file was thereby orphaned. Remove
the orphaned copy.
Signed-off-by: Eugene Loh <eugene.loh at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>
Commit: 486647d6db1fba16dd1b78ac06c1e960d43eae37
https://github.com/oracle/dtrace-utils/commit/486647d6db1fba16dd1b78ac06c1e960d43eae37
Author: Eugene Loh <eugene.loh at oracle.com>
Date: 2025-04-24 (Thu, 24 Apr 2025)
Changed paths:
A test/unittest/ustack/skip_pid0_if_oversubscribed.x
M test/unittest/ustack/tst.kthread.d
A test/unittest/ustack/tst.kthread.x
M test/unittest/ustack/tst.uaddr-pid0.d
M test/unittest/ustack/tst.uaddr-pid0.r.p
A test/unittest/ustack/tst.uaddr-pid0.x
M test/unittest/ustack/tst.ufunc-pid0.d
M test/unittest/ustack/tst.ufunc-pid0.r.p
A test/unittest/ustack/tst.ufunc-pid0.x
M test/unittest/ustack/tst.usym-pid0.d
M test/unittest/ustack/tst.usym-pid0.r.p
A test/unittest/ustack/tst.usym-pid0.x
Log Message:
-----------
test: Skip pid-0 tests on oversubscribed systems
A number of tests check "tick-n /pid==0/" probes. The problem
with this is that a tick-n probe runs on a specific CPU. If that
CPU is fully subscribed, then pid 0 (swapper) will not run. Thus,
the test will take a long time, only to time out.
Change these tests to use profile-n instead of tick-n probes,
improving chances that the test probe will fire on a less subscribed
CPU.
Therefore, also change the .r.p post-processing file so that it uses
only one output line (in case two CPUs manage to write output).
Finally, add skip files in case pid 0 does not fire on any CPU.
Signed-off-by: Eugene Loh <eugene.loh at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>
Commit: 75ca49feadfcd76a9e039537314c3ca59d3f925d
https://github.com/oracle/dtrace-utils/commit/75ca49feadfcd76a9e039537314c3ca59d3f925d
Author: Eugene Loh <eugene.loh at oracle.com>
Date: 2025-04-24 (Thu, 24 Apr 2025)
Changed paths:
M test/unittest/io/tst.fds.aarch64.r
M test/unittest/io/tst.fds.d
M test/unittest/io/tst.fds.r
M test/unittest/io/tst.fds.sparc64.r
M test/unittest/io/tst.fds.x86_64.r
Log Message:
-----------
test: Test fds[] member fi_fs
Signed-off-by: Eugene Loh <eugene.loh at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>
Commit: 38c9ea5126d86d514247cc31d010a26647a07c47
https://github.com/oracle/dtrace-utils/commit/38c9ea5126d86d514247cc31d010a26647a07c47
Author: Kris Van Hees <kris.van.hees at oracle.com>
Date: 2025-04-24 (Thu, 24 Apr 2025)
Changed paths:
M dtrace.spec
Log Message:
-----------
spec: add support for building on OL10
Building on OL10 requires a few adjustments. This patch also removes
some dead portions of the spec file concerning the former translator
generation mechanism.
LTO is also disabled for building DTrace.
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/2335340016e4...38c9ea5126d8
To unsubscribe from these emails, change your notification settings at https://github.com/oracle/dtrace-utils/settings/notifications
More information about the DTrace-devel
mailing list