From owner-freebsd-current@FreeBSD.ORG Wed Jun 23 07:02:13 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 A8B66106564A; Wed, 23 Jun 2010 07:02:13 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B30078FC15; Wed, 23 Jun 2010 07:02:12 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA14342; Wed, 23 Jun 2010 10:02:09 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1ORJyK-0003EY-KN; Wed, 23 Jun 2010 10:02:08 +0300 Message-ID: <4C21B170.2030903@icyb.net.ua> Date: Wed, 23 Jun 2010 10:02:08 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: Hans Petter Selasky References: <201006230238.06831.hselasky@c2i.net> <4C21AE18.4050400@icyb.net.ua> <201006230852.26536.hselasky@c2i.net> In-Reply-To: <201006230852.26536.hselasky@c2i.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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-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 07:02:13 -0000 on 23/06/2010 09:52 Hans Petter Selasky said the following: > 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. I don't dispute that it is found broken in particular environments, I just think that the analysis could be incorrect. > 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. I don't think that this is needed when _not_ cross-building for a different architecture. -- Andriy Gapon