From: Nick Alcock <nick.alcock@oracle.com>
To: Kris Van Hees via DTrace-devel <dtrace-devel@oss.oracle.com>
Cc: dtrace@lists.linux.dev, Kris Van Hees <kris.van.hees@oracle.com>
Subject: Re: [DTrace-devel] [PATCH 3/3] dlibs: report missing CTF and BTF data for vmlinux
Date: Tue, 24 Jun 2025 15:18:47 +0100 [thread overview]
Message-ID: <87wm91p6ig.fsf@esperi.org.uk> (raw)
In-Reply-To: <SJ0PR10MB5672A28ED52DBF398B01EBF8C279A@SJ0PR10MB5672.namprd10.prod.outlook.com> (Kris Van Hees via DTrace-devel's message of "Mon, 23 Jun 2025 19:37:21 -0400")
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...
next prev parent reply other threads:[~2025-06-24 14:18 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-23 23:37 [PATCH 3/3] dlibs: report missing CTF and BTF data for vmlinux Kris Van Hees
2025-06-24 14:18 ` Nick Alcock [this message]
2025-06-24 14:49 ` [DTrace-devel] " Kris Van Hees
2025-07-15 14:23 ` Nick Alcock
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wm91p6ig.fsf@esperi.org.uk \
--to=nick.alcock@oracle.com \
--cc=dtrace-devel@oss.oracle.com \
--cc=dtrace@lists.linux.dev \
--cc=kris.van.hees@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox