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

[Nick Alcock <nick.alcock@oracle.com>]

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)