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

[Kris Van Hees]

________________________________
From: Nick Alcock <nick.alcock at oracle.com>
Sent: Friday, December 1, 2023 10:03 AM
To: dtrace-devel at oss.oracle.com <dtrace-devel at oss.oracle.com>
Cc: Kris Van Hees <kris.van.hees at oracle.com>
Subject: Re: [DTrace-devel] [PATCH v2 03/04] rawtp: report lockmem issues when determining rawtp argument count

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*.

Yes, that is another factor.

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.

Well, the test that is added with the new type-based mechanism already covers the case where the type-based mechanism falls back to the BPF-based approach.  That is not an issue.  The problem is that testing whether we get the proper error response when lockmem is too low is not something we can do in a truly predictable manner on all environments.

I'm looking at a test that does some best effort - if it can detect that setting lockmem seems​ to not have an effect, it reports error code 67 which should be interpreted by runtest.sh as XFAIL.  I think that is the best I can do.

>                                                 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.

But what you suggest is not at runtime.  At runtime, it doesn't matter what libraries are on the system because if dtrace was built on a different system and linked the CTF library (whichever one) statically, you don't know.

> (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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://oss.oracle.com/pipermail/dtrace-devel/attachments/20231201/a4b1f85c/attachment-0001.html>