[DTrace-devel] [PATCH v2 04/04] rawtp: retrieve probe arguments from CTF data

[Kris Van Hees]

On Fri, Dec 01, 2023 at 12:35:02AM -0500, Eugene Loh via DTrace-devel wrote:
> On 11/30/23 10:59, Kris Van Hees via DTrace-devel wrote:
> 
> > We were determining the number of arguments using a trial-and-error
> > approach with minimal BPF programs.  If there is CTF type data for
> > the raw tracepoints (in the form of a function prototype), we use
> > that because it also gives us the types of the arguments.
> > 
> > If no such CTF data is available, we fall back to the trial-and-error
> > approach.
> > 
> > The included test will fail if the fallback is used.  There is no way
> > to force the fallback to get triggered explicitly.

I forgot to update this commit message when I added the .r.p to ensure that
we can cover both cases.  Thank you for catching this mistake.  I'll remove
these lines.

> I don't understand.  The fallback will be used on OL7.  So are you saying
> the test will fail on OL7?  Shouldn't it have the appropriate .x?
> 
> But the .r.p thinks that uint64_t (that is, the fallback) is okay. So that
> means the test will pass even if the fallback is used.
> 
> And that means that if the mechanism is broken and we return the garbage
> types (uint64_t) rather than the actual types (struct task_struct), the test
> will still pass.

They are not garbage types - they are the generic type for the arguments.
> 
> I propose two tests:
> 
> *)  one test that tolerates the fallback (like the test that's already in
> the patch)
> 
> *)  another test that insists on the correct types;  it should have:
>        - a .x file to avoid OL7 problems
>        - a simpler .r.p file that doesn't filter the results so much

I just sent an email on this topic of testing that is specific to OL7.  We
shouldn't be limiting ourselves to just that because the conditions are not
OL7-specific but rather a combination of circumstances that happen to take
place on OL7.

Anyway, the .r.p script validates the types already...  Either we get the
generic type (which shows the fallback was used) or we get the correct type
(struct task_struct *) which shows that the correct types were found.  Those
are both valid PASS conditions - we are not testing here what the system
supports - only that it can provide us with probe argument type data in a way
that we can use.

> > diff --git a/test/unittest/providers/rawtp/tst.lv-sched_process_fork.r b/test/unittest/providers/rawtp/tst.lv-sched_process_fork.r
> > +PROBE rawtp sched sched_process_fork
> > +
> > +	Argument Types
> > +		args[0]: TYPE-OK
> > +		args[1]: TYPE-OK
> > +
> > diff --git a/test/unittest/providers/rawtp/tst.lv-sched_process_fork.r.p b/test/unittest/providers/rawtp/tst.lv-sched_process_fork.r.p
> > +#!/usr/bin/awk -f
> > +NR == 1 { next; }
> > +NR == 2 { print "PROBE", $2, $3, $NF; next; }
> > +/args\[[0-9]+\]: uint64_t$/ { sub(/:.*$/, ": TYPE-OK"); }
> > +/args\[[0-9]+\]: struct task_struct \*$/ { sub(/:.*$/, ": TYPE-OK"); }
> > +/^ *[0-9]+/ { exit; }
> > +{ print; }
> > diff --git a/test/unittest/providers/rawtp/tst.lv-sched_process_fork.sh b/test/unittest/providers/rawtp/tst.lv-sched_process_fork.sh
> > +$dtrace $dt_flags -lvn rawtp:::sched_process_fork
> > +exit $?
> 
> _______________________________________________
> DTrace-devel mailing list
> DTrace-devel at oss.oracle.com
> https://oss.oracle.com/mailman/listinfo/dtrace-devel