Re: 12.3-RC1 fails to compile perl,tcl86 (ipfw dtrace issue)

On Sun, Nov 21, 2021 at 10:46:30PM +0100, Peter wrote:
> ## 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!

Hmm, that is indeed surprising.  I'm able to reproduce the problem
locally.

> 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?)

How did you come to that conclusion?

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