public inbox for dtrace@lists.linux.dev
 help / color / mirror / Atom feed
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...

  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