From owner-freebsd-current@FreeBSD.ORG Wed Jun 23 00:41:00 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 BD67E1065670; Wed, 23 Jun 2010 00:41:00 +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 DDE838FC13; Wed, 23 Jun 2010 00:40:59 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=9zy2FLL-uPcA:10 a=yQWWgrYGNuUA:10 a=kj9zAlcOel0A:10 a=M8b_wTzEtboA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=IGmblQ1dLY3wUGMpuGUA:9 a=EPc1bLlpiiolXB59LsWQj2YinIsA:4 a=CjuIK1q_8ugA: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 1368958191; Wed, 23 Jun 2010 02:40:58 +0200 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Wed, 23 Jun 2010 02:38:06 +0200 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; amd64; ; ) X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?utf-8?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?utf-8?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7CoTlKM?= =?utf-8?q?usi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201006230238.06831.hselasky@c2i.net> Cc: freebsd-current@freebsd.org Subject: [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 00:41:00 -0000 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 Good module: $ nm -o ./cuse4bsd.ko | grep sys ./cuse4bsd.ko:000028cc r __set_sysinit_set_sym_cuse_kern_init_sys_init ./cuse4bsd.ko:000028c8 r __set_sysuninit_set_sym_cuse_kern_uninit_sys_uninit ./cuse4bsd.ko: U __start_set_sysctl_set ./cuse4bsd.ko:000028cc A __start_set_sysinit_set ./cuse4bsd.ko:000028c8 A __start_set_sysuninit_set ./cuse4bsd.ko: U __stop_set_sysctl_set ./cuse4bsd.ko:000028d0 A __stop_set_sysinit_set ./cuse4bsd.ko:000028cc A __stop_set_sysuninit_set ./cuse4bsd.ko:00003194 d cuse_kern_init_sys_init ./cuse4bsd.ko:00003184 d cuse_kern_uninit_sys_uninit --HPS