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. --HPSReceived on Wed Jun 23 2010 - 04:55:21 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:04 UTC