[DTrace-devel] [PATCH 05/12] Fix the -xctfpath option

[Kris Van Hees]

On Mon, Jul 18, 2022 at 12:28:42PM -0700, Eugene Loh via DTrace-devel wrote:
> Reviewed-by: Eugene Loh <eugene.loh at oracle.com>
> though maybe it also makes sense for Nick to take a peek?

Yes, Nick definitely needs to chime in as well.  Especially about the core.

> In the /dev/null case, is a core dump really what we want?  I realize this
> question might be out-of-scope for this particular patch, but if a core dump
> is not really the desired behavior, maybe it makes more sense to fix the
> core dump first and then deal with the -xctfpath test.

Yes, which was something Nick was looking at I believe.  But digging through
outstanding patches for rewview, I only see one that partly fixes this (or
might fix this), so I will take a look and see what I can do.  If it needs
Nick to fix this, I would keep the test as-is for now since it does test the
correct thing: whether -xctfpath is accepted and processed correctly.

But of course, dtrace should not dump core for anything.

> By the way, is that why the test is a .sh?  If there were no core dump,
> maybe the test could be simpler?  Some sort of err.ctfpath.d:
>     /* @@runtest-opts: -xctfpath=/dev/null */
>     BEGIN { exit(0); }
> 
> Regarding tst.ctfpath.sh, there is again a dangling tab (line with nothing
> other than a tab).  Also, why do you use "rm core" rather than just setting
> "ulimit -c 0"?
> 
> Should there also be a "positive" test?  I do not know what, but I imagine
> something like a tst.ctfpath.d:
>     /* @@runtest-opts: -xctfpath=/lib/modules/$(uname
> -r)/kernel/vmlinux.ctfa */
>     BEGIN { exit(0); }

Well, this test *is* a positive test.  It verifies that the -xctfpath option is
recognized, accepted, and processed.  It just looks weird because I use a
dtrace failure to determine that the option took.  It is the most obvious way
to test this.

The test you propose would actually pass if -xctfpath was ignored altogether,
which is certainly not what we want.