From: Kris Van Hees <kris.van.hees@oracle.com>
To: Alan Maguire <alan.maguire@oracle.com>
Cc: Kris Van Hees <kris.van.hees@oracle.com>,
Eugene Loh <eugene.loh@oracle.com>,
dtrace@lists.linux.dev, dtrace-devel@oss.oracle.com
Subject: Re: [DTrace-devel] [PATCH] test/utils: add more reliable "get remote address" approach
Date: Tue, 8 Jul 2025 16:13:49 -0400 [thread overview]
Message-ID: <aG17/ZbpZHUCkE+J@oracle.com> (raw)
In-Reply-To: <db9e497a-b2b5-4b44-840c-efdead15fb9e@oracle.com>
On Tue, Jul 08, 2025 at 08:04:41PM +0100, Alan Maguire wrote:
<< omitted >>
> thanks; tried with build/run-dtrace with same result. However by adding
> some debug logging I think I've discovered the root cause; the order of
> .d file sorting seems to be different in the build/dlibs versus
> /usr/lib64/dtrace case, and the problem is that tcp.d actually
> implicitly relies on ip.d for ipinfo_t . We get lucky in the sort order for
> /usr/lib64/dtrace, and because an ipaddr_t * gets added during ip.d
> processing, by the time we lookup "ipaddr_t *" in tcp.d it's already in
> the D CTF dict. I _think_ the ipaddr_t * gets added as a side effect of
> the fact that there are fields of type ipaddr_t in the translated
> ipv4info_t in ip.d
>
> However in the problematic case with build/run-dtrace , net.d is still
> loaded first, and then tcp.d is loaded immediately after without an
> intervening load of ip.d. As a result we have no "ipaddr_t *", hence
>
> dtrace: invalid probe specifier ip:::send /args[4]->ipv4_protocol ==
> IPPROTO_TCP/ { @c[args[2]->ip_saddr, args[4]->ipv4_protocol] = count();
> } END { printa(@c); }:
> "/home/opc/src/dtrace-utils/build/dlibs/6.10/tcp.d", line 183: failed to
> resolve type of inet_ntoa arg#1 (ipaddr_t *): Unknown type name
>
> To fix this I think the right answer is to change the dependency tcp.d
> has on ip.d, from
>
> #pragma D depends_on provider ip
>
> to
>
> #pragma D depends_on library ip.d
>
> This is needed for other reasons (ipinfo_t declaration for example), but
> with that change the problem is resolved.
Sounds like a good solution!
prev parent reply other threads:[~2025-07-08 20:13 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-03 11:33 [PATCH] test/utils: add more reliable "get remote address" approach Alan Maguire
2025-07-03 16:43 ` [DTrace-devel] " Eugene Loh
2025-07-03 16:59 ` Alan Maguire
2025-07-03 17:06 ` Eugene Loh
2025-07-03 18:02 ` Alan Maguire
2025-07-03 18:26 ` Kris Van Hees
2025-07-03 18:41 ` Alan Maguire
2025-07-03 19:03 ` Kris Van Hees
2025-07-03 20:23 ` Alan Maguire
2025-07-03 20:59 ` Kris Van Hees
2025-07-03 22:36 ` Kris Van Hees
2025-07-07 16:32 ` Alan Maguire
2025-07-07 16:53 ` Kris Van Hees
2025-07-07 18:14 ` Alan Maguire
2025-07-07 19:55 ` Kris Van Hees
2025-07-07 21:51 ` Alan Maguire
2025-07-08 1:34 ` Kris Van Hees
2025-07-08 17:19 ` Alan Maguire
2025-07-08 17:30 ` Kris Van Hees
2025-07-08 19:04 ` Alan Maguire
2025-07-08 20:13 ` Kris Van Hees [this message]
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=aG17/ZbpZHUCkE+J@oracle.com \
--to=kris.van.hees@oracle.com \
--cc=alan.maguire@oracle.com \
--cc=dtrace-devel@oss.oracle.com \
--cc=dtrace@lists.linux.dev \
--cc=eugene.loh@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.