[DTrace-devel] [PATCH 3/3] dlibs: report missing CTF and BTF data for vmlinux

[Kris Van Hees]

On Tue, Jun 24, 2025 at 03:18:47PM +0100, Nick Alcock wrote:
> On 24 Jun 2025, Kris Van Hees via DTrace-devel spake thusly:
> 
> > If the kernel is not compiled with CTF and/or BTF enabled, DTrace will
> > not work.  This used to result in an assert, which is rather harsh and
> > not user friendly.  We now report a nice error.
> >
> > Doing this in the pragma 'depends on' handling may seem odd but that is
> > where the initial type data load is triggered.  If for some strange
> > reason no dlibs exist (and thus no 'depends on' are encountered), the
> > compiler will complain about missing type information anyway.
> 
> I'm honestly wondering if we should do a type lookup for something
> trivial that will always be present in a hardwired fashion, so we don't
> have to depend on a side effect this delicate (which will fail the first
> time a .d is introduced which sorts lexicographically before any
> existing one, depends on any types other than the built-in ones -- which
> is why errno.d doesn't trigger a type lookup -- and does not start with
> 
> #pragma D depends_on module vmlinux
> 
> like io.d happens to.)

That is why I wrote that 2nd paragraph, right?  If a .d file depends on any
other module, it will still report an error:

	No type data (CTF or BTF) found for <module-name>

And if there are no dependencies (or e.g. the extreme case of no dlibs), you
still get a nice error, e.g. if you use curthread and there is no type data
and no dlibs to trigger the error report this patch adds:

	failed to resolve type vmlinux`struct task_struct * for identifier curthread: Cannot read object file or modules.dep

That is because of patch 2/3 ensuring that we do not bail with an assert, but
instead let error reporting do its work.

> > Signed-off-by: Kris Van Hees <kris.van.hees at oracle.com>
> 
> Reviewed-by: Nick Alcock <nick.alcock at oracle.com>
> 
> even if I think this feels wrong, it does work...