public inbox for dtrace@lists.linux.dev
 help / color / mirror / Atom feed
From: Kris Van Hees <kris.van.hees@oracle.com>
To: Nick Alcock <nick.alcock@oracle.com>
Cc: Kris Van Hees via DTrace-devel <dtrace-devel@oss.oracle.com>,
	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 10:49:43 -0400	[thread overview]
Message-ID: <aFq7B7evUkbsxJ2W@oracle.com> (raw)
In-Reply-To: <87wm91p6ig.fsf@esperi.org.uk>

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

  reply	other threads:[~2025-06-24 14:49 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 ` [DTrace-devel] " Nick Alcock
2025-06-24 14:49   ` Kris Van Hees [this message]
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=aFq7B7evUkbsxJ2W@oracle.com \
    --to=kris.van.hees@oracle.com \
    --cc=dtrace-devel@oss.oracle.com \
    --cc=dtrace@lists.linux.dev \
    --cc=nick.alcock@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