From owner-freebsd-current@FreeBSD.ORG Wed Jun 23 14:43:34 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 6CE45106566C for ; Wed, 23 Jun 2010 14:43:34 +0000 (UTC) (envelope-from kris@pcbsd.org) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) by mx1.freebsd.org (Postfix) with ESMTP id 4D4588FC20 for ; Wed, 23 Jun 2010 14:43:34 +0000 (UTC) Received: from mail.ixsystems.com (localhost [127.0.0.1]) by mail.iXsystems.com (Postfix) with ESMTP id C3AE8A6643E; Wed, 23 Jun 2010 07:43:33 -0700 (PDT) Received: from mail.iXsystems.com ([127.0.0.1]) by mail.ixsystems.com (mail.ixsystems.com [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 63578-09; Wed, 23 Jun 2010 07:43:33 -0700 (PDT) Received: from [192.168.0.55] (unknown [75.131.46.136]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id D88F3A66429; Wed, 23 Jun 2010 07:43:32 -0700 (PDT) Message-ID: <4C221D93.6020800@pcbsd.org> Date: Wed, 23 Jun 2010 10:43:31 -0400 From: Kris Moore User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100414 Thunderbird/3.0.4 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> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Andriy Gapon 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:43:34 -0000 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. -- Kris Moore PC-BSD Software iXsystems