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

On Mon, Nov 22, 2021 at 10:45:09AM -0500, Mark Johnston wrote:
> 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?

Indeed, the problem had to do with handling of bitfield types in libctf.
The problem you found is fixed by
https://cgit.freebsd.org/src/commit/?id=3cbb4cc200f8a0ad7ed08233425ea54524a21f1c
but that change was not merged to 12.  I just merged it to stable/12 and
will try to get both libctf changes into 12.3, as both are required for
dtrace to work properly while ipfw.ko is loaded.