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

[Nick Alcock]

On 1 Dec 2023, Kris Van Hees stated:

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

Oh right!

> 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 think lockmem being too low *and* CTF/BTF being damaged probably is a
test too far -- except that it invokes a bunch of code that is otherwise
untested :/

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

Errr... I thought this depended on what library dtrace was *linked*
with, which of course it can determine at compile time using the method
above? ... oh, you mean the *testcase* has to determine it. The only
approach I can think of there is to add a line to dtrace -vV output
indicating which variant we are using, which seems like a good idea for
debuggability reasons anyway. Then the testcase could just check the -vV
output for the relevant line.

-- 
NULL && (void)