From owner-freebsd-current@FreeBSD.ORG Wed Jun 23 14:58:38 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 013B4106566B for ; Wed, 23 Jun 2010 14:58:38 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id 5C6178FC1C for ; Wed, 23 Jun 2010 14:58:36 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=nXlDabneoW0A:10 a=uEzv4HemXiYA:10 a=8nJEP1OIZ-IA:10 a=M8b_wTzEtboA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=_-VI2dNxeZ1EX8AoQcgA:9 a=SUjKCEx6vo7bk_F_oCIA:7 a=h9oNJ8-_25veWjD1XBcogByiemcA:4 a=wPNLvfGTeEIA:10 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 1374035822; Wed, 23 Jun 2010 16:58:34 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Wed, 23 Jun 2010 16:55:43 +0200 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; amd64; ; ) References: <201006230238.06831.hselasky@c2i.net> <201006230852.26536.hselasky@c2i.net> <4C221D93.6020800@pcbsd.org> In-Reply-To: <4C221D93.6020800@pcbsd.org> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201006231655.43671.hselasky@c2i.net> Cc: Andriy Gapon , Kris Moore Subject: Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 14:58:38 -0000 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. > >>> > >>> > >>> > >>> 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 > >>> @@ -30,4 +30,10 @@ > >>> 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 > >>> > >>> 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