Date: Mon, 22 Nov 2021 11:05:43 -0500 From: Mark Johnston <markj@freebsd.org> To: Peter <pmc@citylink.dinoex.sub.org> Cc: freebsd-stable@freebsd.org Subject: Re: 12.3-RC1 fails to compile perl,tcl86 (ipfw dtrace issue) Message-ID: <YZu/1x3eITluMD0w@nuc> In-Reply-To: <YZu7Bet6WUgQj8tS@nuc> References: <YZq%2BNlYyc8CVM/Fu@gate.intra.daemon.contact> <YZu7Bet6WUgQj8tS@nuc>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YZu/1x3eITluMD0w>