Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1

On Wednesday 23 June 2010 16:43:31 Kris Moore wrote:
> On 06/23/2010 02:52, Hans Petter Selasky wrote:
> > On Wednesday 23 June 2010 08:47:52 Andriy Gapon wrote:
> >> on 23/06/2010 03:38 Hans Petter Selasky said the following:
> >>> Hi,
> >>>
> >>> I'm creating a new thread on this issue.
> >>>
> >>> On Tue, Jun 22, 2010 at 04:39:17PM -0400, Ryan Stone wrote:
> >>>> I saw similar behaviour a couple of years ago when I switched from
> >>>> using gcc 4.0.2 to gcc 4.3.0 to compile some out-of-tree KLD modules.
> >>>> The problem ended up being a change in the linker script used by GNU
> >>>> ld for linking kernel modules.  It used to always put some magic
> >>>> symbols used by the linker to implement things like sysinits into the
> >>>> module.  It was changed to only provide those symbols, which
> >>>> apparently means that the linker would discard those symbols if
> >>>> nothing referenced them(and nothing did reference them).  I had to
> >>>> work around it by adding the following to my link line:
> >>>>
> >>>> -u __start_set_sysinit_set -u __start_set_sysuninit_set \
> >>>> -u __start_set_sysctl_set -u __start_set_modmetadata_set \
> >>>> -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \
> >>>> -u __stop_set_sysctl_set -u __stop_set_modmetadata_set
> >>>
> >>> It appears many kmods are broken because the linker is stripping away
> >>> static data declared with the section attribute in FreeBSD 8.1-RC1.
> >>>
> >>> <cite>
> >>>
> >>> I added those lines to the LDFLAGS in Makefile.kmod in the cuse4bsd
> >>> port made the module and the result loads and creates the /dev/cuse
> >>> file.
> >>>
> >>> Here's a diff relative to
> >>> /usr/ports/multimedia/cuse4bsd-kmod/work/cuse4bsd-kmod-0.1.11 just so
> >>> it's clear what I did.
> >>>
> >>>
> >>> --- Makefile.kmod.orig  2010-02-11 03:28:02.000000000 -0800
> >>> +++ Makefile.kmod       2010-06-22 14:02:52.000000000 -0700
> >>> _at__at_ -30,4 +30,10 _at__at_
> >>>   KMOD=  cuse4bsd
> >>>   SRCS=  cuse4bsd_kmod.c device_if.h bus_if.h vnode_if.h
> >>>
> >>> +LDFLAGS += -u __start_set_sysinit_set -u __start_set_sysuninit_set \
> >>> + -u __start_set_sysctl_set -u __start_set_modmetadata_set \
> >>> + -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \
> >>> + -u __stop_set_sysctl_set -u __stop_set_modmetadata_set
> >>> +
> >>> +
> >>>   .include<bsd.kmod.mk>
> >>>
> >>> Running nm -o on the two modules, the difference seems to be that the
> >>> -u results in some additional absolute symbols being defined:
> >>>
> >>> Bad module:
> >>> $ nm -o /boot/modules/cuse4bsd.ko| grep sys
> >>> /boot/modules/cuse4bsd.ko:0000275c r
> >>> __set_sysinit_set_sym_cuse_kern_init_sys_init
> >>> /boot/modules/cuse4bsd.ko:00002758 r
> >>> __set_sysuninit_set_sym_cuse_kern_uninit_sys_uninit
> >>> /boot/modules/cuse4bsd.ko:00003194 d cuse_kern_init_sys_init
> >>> /boot/modules/cuse4bsd.ko:00003184 d cuse_kern_uninit_sys_uninit
> >>
> >> I am not sure if this analysis is correct.
> >> I tested on head and stable/8 and my nm output is exactly like above
> >> ("bad module"), still the module loads fine and creates /dev/cuse.
> >>
> >> I don't think there were any recent changes related to build
> >> infrastructure or linker in 8.1.
> >>
> >> Please consider other possibilities.
> >
> > I installed PC-BSD 8.1-RC1 and the stock cuse4bsd module is broken.
> > Andriy, make sure that you re-make the toolchain before building the
> > module in question. Also I think you have to:
> >
> > cd /usr/src ; make buildenv TARGET_ARCH=xxx_target
> >
> > Then you cd to the module directory and type make.
> >
> > --HPS
> 
> Are you going to be updating the port soon to fix the build? We're just
> doing a regular "make install" on the cuse4bsd-kmod port for our RC1
> build, and it would be nice to have this fixed for 8.1-Release.
> 

Hi,

Not unless there is a bug in my module. I'm a little bit busy right now, 
though I think that other modules like "fuse.ko" might be affected aswell. 

Could you try to make a cuse4bsd build on a stock 8-stable and compare the 
resulting cuse4bsd.ko (i386 build) like described earlier in this thread.

Or something like this:

objdump -D -x cuse4bsd.ko > a.txt
objdump -D -x cuse4bsd.ko > b.txt

diff -u a.txt b.txt

What compiler did you bundle with the PCBSD 8.1 RC1 and how did you build the 
cuse4bsd ports module? Did you use something like clang?

I haven't checked too much yet, but it appears that like Andriy is reporting 
that it's not a problem for everyone. When booting PCBSD 8.1 RC1 you will see 
warnings from the webcamd rc.d.

--HPS