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

From: Peter <pmc_at_citylink.dinoex.sub.org>
Date: Sun, 21 Nov 2021 21:46:30 UTC
## 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