Date: Sun, 21 Nov 2021 22:46:30 +0100 From: Peter <pmc@citylink.dinoex.sub.org> To: freebsd-stable@freebsd.org Subject: Re: 12.3-RC1 fails to compile perl,tcl86 (ipfw dtrace issue) Message-ID: <YZq%2BNlYyc8CVM/Fu@gate.intra.daemon.contact>
next in thread | raw e-mail | index | archive | help
## this seems not have arrived on the list at first send ## > dtrace: failed to establish error handler: "/usr/lib/dtrace/ipfw.d", > line 106: failed to copy type of 'inp': Conflicting type is already defined > That file ipfw.d appears to be new in 12.3, but I'm clueless what > the error means (and why it happens only to me). I figured out why - I have "device dtraceall" in my kernel. This is reproducible: > root@y12y:/ # dtrace -h > dtrace: -h requires one or more scripts or enabling options > root@y12y:/ # kldload dtraceall > root@y12y:/ # dtrace -h > dtrace: failed to establish error handler: "/usr/lib/dtrace/ipfw.d", line 106: failed to copy type of 'inp': Conflicting type is already defined > root@y12y:/ # kldunload dtraceall > root@y12y:/ # dtrace -h > dtrace: -h requires one or more scripts or enabling options But we do already have a bug (#254483) for this error. This bug was closed as duplicate to bug #258763, and the latter one was closed as solved with a fix as stated here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258763#c7 But the fancy is: 1. that fix appears to have missed the releng/12.3 branch by three days, so it is not in the code. But also 2. if applied, (*surprize*) that fix does NOT help! More than one thing is wrong here, and bug #254483 is *not* a duplicate to #258763. The failure does NOT come from code covered by Mark Johnstons fix. It comes from a neighboring section where Integers are compared, and it fails with a type conflict 8bit vs. 32bit. The problem must be within /usr/lib/dtrace/ipfw.d - and indeed it is (irrelevant parts stripped away): > typedef struct ipfw_match_info { > struct mbuf *m; > } ipfw_match_info_t; > > translator ipfw_match_info_t < struct ip_fw_args *p > { > m = p->m; > }; This does not work. Within the 'struct mbuf' definition is a construct, that looks like this: > uint32_t m_type:8, /* type of data in this mbuf */ > m_flags:24; /* flags; see below */ And it seems that is somehow the cause for the integer size conflict (not implemented?) In the neighboring file /usr/lib/dtrace/mbuf.d this is done distinctively: > translator mbufinfo_t < struct mbuf *p > { > mbuf_addr = (uintptr_t)p; > m_data = p->m_data; > m_len = p->m_len; > m_type = p->m_type & 0xff000000; > m_flags = p->m_type & 0x00ffffff; >}; So probably we should just duplicate that approach for ipfw. Or, could that definition be directly included and called? Does dtrace allow one tranlation to call another? I can't answer that, have never been that deep in dtrace - but I really love the idea that we now get means to look into ipfw. Comes in handy and at the right time. :) cheerio, PMc
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YZq%2BNlYyc8CVM/Fu>