<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="appendonsend"></div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div dir="ltr"><font face="Calibri, sans-serif" style="font-size: 11pt; color: rgb(0, 0, 0);"><b>From:</b> Nick Alcock <nick.alcock@oracle.com><br>
<b>Sent:</b> Friday, December 1, 2023 10:03 AM<br>
<b>To:</b> dtrace-devel@oss.oracle.com <dtrace-devel@oss.oracle.com><br>
</font></div>
<div id="divRplyFwdMsg" dir="ltr" class="elementToProof"><font face="Calibri, sans-serif" style="font-size: 11pt; color: rgb(0, 0, 0);"><b>Cc:</b> Kris Van Hees <kris.van.hees@oracle.com><br>
</font></div>
<div dir="ltr"><font face="Calibri, sans-serif" style="font-size: 11pt; color: rgb(0, 0, 0);"><b>Subject:</b> Re: [DTrace-devel] [PATCH v2 03/04] rawtp: report lockmem issues when determining rawtp argument count</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="PlainText elementToProof">On 1 Dec 2023, Kris Van Hees via DTrace-devel spake thusly:<br>
> The *real* conditions are systems where (1) libdtrace-ctf is used rather than<br>
> libctf *and* (2) lockmem poses a limitations.<br>
<br>
... or 3) for whatever reason, the [CB]TF is missing prototypes for<br>
these trace functions. Sure, not very likely, but not *impossible*.<br>
<br>
Yes, that is another factor.<br>
<br>
A magic undocumented testing option or env var to force use of the<br>
fallback for a couple of testcases might help here (akin to<br>
DTRACE_OPT_DEBUGASSERT=mutexes) -- or maybe this is just overkill. I<br>
know I'm prone to that :)<br>
<br>
It might not be overkill once we no longer test new code on OL7 though,<br>
since we probably *do* still want the fallback to not rust, unless we<br>
plan to remove it entirely.<br>
<br>
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.</div>
<div class="PlainText elementToProof"><br>
</div>
<div class="PlainText elementToProof">I'm looking at a test that does some best effort - if it can detect that setting lockmem
<b>seems</b> 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. <br>
<br>
> Checking (at runtime) whether<br>
> we are dealing with libdtrace-ctf vs libctf is not that easy because we'd need<br>
> to look at libdtrace.so and somehow determine which library it was linked with<br>
<br>
There are a bunch of #defines in ctf-api.h that you could check against:<br>
though none are actually *intended* for this purpose, they'll work. (No<br>
released version of libdtrace-ctf has any CTF_LINK_* flags: no version<br>
of libdtrace-ctf, released or not, has CTF_LINK_NONDEDUP,<br>
CTF_LINK_EMPTY_CU_MAPPINGS, CTF_LINK_OMIT_VARIABLES_SECTION,<br>
CTF_LINK_NO_FILTER_REPORTED_SYMS, or CTF_MN_RECURSE, and<br>
CTF_LINK_NONDEDUP in particular is as old as the nondeduplicating CTF<br>
linker, 2019 or thereabouts.)<br>
<br>
This is gross, but would work. None of those #defines are expected ever<br>
to go away.<br>
<br>
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.<br>
<br>
> (and on OL we perform a static link for some reason whereas on e.g. Debian we<br>
<br>
Because OL and RHEL make libbfd and libctf .so's into linker scripts<br>
that statically link the libraries in question. This is justifiable for<br>
libbfd (which has no stable API or ABI), but really not for libctf<br>
(which does). I really should ask Nick Clifton why this is done for<br>
libctf...<br>
<br>
-- <br>
NULL && (void)<br>
</div>
</span></font></div>
</body>
</html>