Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 16 Dec 2024 22:02:59 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 283359] dtrace -h is broken again
Message-ID:  <bug-283359-227-cQKLF14xSg@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-283359-227@https.bugs.freebsd.org/bugzilla/>
References:  <bug-283359-227@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D283359

--- Comment #4 from Mark Johnston <markj@FreeBSD.org> ---
(In reply to shamaz.mazum from comment #2)
Thanks for the repro hints.

The "problem" is that there's no kernel in this jail, so dtrace has no acce=
ss
to the CTF info.  But /usr/lib/dtrace/ipfw.d (parsed only when ipfw.ko is
loaded) relies on some definitions, e.g., for in_addr_t and struct ip6_addr=
.=20
If I install kernel.txz as well, "dtrace -h" works again.

We've had these kinds of problems before.  The workaround is generally to a=
dd
"-x nolibs" to the "dtrace -h" invocation in various build scripts.  "-x
nolibs" means that the definitions in /usr/lib/dtrace won't be processed (as
they aren't needed for usdt probes in general).

In fact, it looks like the perl configure script knows about this and tries=
 to
add "-x nolibs" if dtrace(1) accepts that option.  Why doesn't that work?  =
Can
you share the log where the perl build failed?

In any case, I think adding "#pragma D depends_on module kernel" to ipfw.d =
is
sufficient to prevent "dtrace -h" from trying to process the file.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-283359-227-cQKLF14xSg>