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

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

[Kris Van Hees]

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.

Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>
---
 libdtrace/dt_pragma.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/libdtrace/dt_pragma.c b/libdtrace/dt_pragma.c
index 0c97edfc..d29e6e28 100644
--- a/libdtrace/dt_pragma.c
+++ b/libdtrace/dt_pragma.c
@@ -202,7 +202,15 @@ dt_pragma_depends(const char *prname, dt_node_t *cnp)
 		found = dt_provider_lookup(dtp, nnp->dn_string) != NULL;
 	else if (strcmp(cnp->dn_string, "module") == 0) {
 		dt_module_t *mp = dt_module_lookup_by_name(dtp, nnp->dn_string);
-		found = mp != NULL && dt_module_getctf(dtp, mp) != NULL;
+
+		if (mp == NULL)
+			found = B_FALSE;
+		else if (dt_module_getctf(dtp, mp) != NULL)
+			found = B_TRUE;
+		else
+			xyerror(D_SYM_NOTYPES,
+				"No type data (CTF or BTF) found for %s",
+				mp->dm_name);
 	} else if (strcmp(cnp->dn_string, "library") == 0) {
 		if (yypcb->pcb_cflags & DTRACE_C_CTL) {
 			assert(dtp->dt_filetag != NULL);
-- 
2.43.5

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

[Nick Alcock]

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

> Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>

Reviewed-by: Nick Alcock <nick.alcock@oracle.com>

even if I think this feels wrong, it does work...

Re: [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@oracle.com>
> 
> Reviewed-by: Nick Alcock <nick.alcock@oracle.com>
> 
> even if I think this feels wrong, it does work...

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

[Nick Alcock]

On 24 Jun 2025, Kris Van Hees uttered the following:

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

Ah, I missed that there was already an error-handling case for this that
was just being skipped due to the early exit.

Looks fine then.

-- 
NULL && (void)