[DTrace-devel] [PATCH v2 03/04] rawtp: report lockmem issues when determining rawtp argument count

[Nick Alcock]

On 1 Dec 2023, Kris Van Hees via DTrace-devel spake thusly:
> The *real* conditions are systems where (1) libdtrace-ctf is used rather than
> libctf *and* (2) lockmem poses a limitations.

... or 3) for whatever reason, the [CB]TF is missing prototypes for
these trace functions. Sure, not very likely, but not *impossible*.

A magic undocumented testing option or env var to force use of the
fallback for a couple of testcases might help here (akin to
DTRACE_OPT_DEBUGASSERT=mutexes) -- or maybe this is just overkill. I
know I'm prone to that :)

It might not be overkill once we no longer test new code on OL7 though,
since we probably *do* still want the fallback to not rust, unless we
plan to remove it entirely.

>                                                 Checking (at runtime) whether
> we are dealing with libdtrace-ctf vs libctf is not that easy because we'd need
> to look at libdtrace.so and somehow determine which library it was linked with

There are a bunch of #defines in ctf-api.h that you could check against:
though none are actually *intended* for this purpose, they'll work. (No
released version of libdtrace-ctf has any CTF_LINK_* flags: no version
of libdtrace-ctf, released or not, has CTF_LINK_NONDEDUP,
CTF_LINK_EMPTY_CU_MAPPINGS, CTF_LINK_OMIT_VARIABLES_SECTION,
CTF_LINK_NO_FILTER_REPORTED_SYMS, or CTF_MN_RECURSE, and
CTF_LINK_NONDEDUP in particular is as old as the nondeduplicating CTF
linker, 2019 or thereabouts.)

This is gross, but would work. None of those #defines are expected ever
to go away.

> (and on OL we perform a static link for some reason whereas on e.g. Debian we

Because OL and RHEL make libbfd and libctf .so's into linker scripts
that statically link the libraries in question. This is justifiable for
libbfd (which has no stable API or ABI), but really not for libctf
(which does). I really should ask Nick Clifton why this is done for
libctf...

-- 
NULL && (void)