From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 23 06:55:21 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4961E106566C; Wed, 23 Jun 2010 06:55:21 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.swip.net [212.247.154.225]) by mx1.freebsd.org (Postfix) with ESMTP id 710DA8FC1A; Wed, 23 Jun 2010 06:55:20 +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=Czt-lxB3K3gCxCdIjiAA:9 a=doJ4I_PN3phXl2CbSDgA:7 a=cNb5hjClQZjlamADw7sB3-yCQ_MA:4 a=wPNLvfGTeEIA:10 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe08.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 1369002294; Wed, 23 Jun 2010 08:55:18 +0200 From: Hans Petter Selasky To: Andriy Gapon Date: Wed, 23 Jun 2010 08:52:26 +0200 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; amd64; ; ) References: <201006230238.06831.hselasky@c2i.net> <4C21AE18.4050400@icyb.net.ua> In-Reply-To: <4C21AE18.4050400@icyb.net.ua> 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: <201006230852.26536.hselasky@c2i.net> Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 06:55:21 -0000 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