From owner-freebsd-current Tue Apr 1 08:35:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA10674 for current-outgoing; Tue, 1 Apr 1997 08:35:54 -0800 (PST) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA10662 for ; Tue, 1 Apr 1997 08:35:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by nlsystems.com (8.8.5/8.8.5) with SMTP id RAA04139; Tue, 1 Apr 1997 17:34:20 +0100 (BST) Date: Tue, 1 Apr 1997 17:34:18 +0100 (BST) From: Doug Rabson To: John Polstra cc: phk@critter.dk.tfs.com, current@FreeBSD.ORG Subject: Re: A new Kernel Module System In-Reply-To: <199704011627.IAA01496@austin.polstra.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 1 Apr 1997, John Polstra wrote: > > Exactly what I was thinking. PIC has no benefits for the kernel. > > The only thing I would need from the a.out shlib format is the > > relocations and runtime symbol table. > > I don't think you can get a runtime symbol table, unless you're building > a shared object, i.e., using PIC. You'll have to use the "normal" > symbol table. That shouldn't be a problem as far as I can see. I am pretty sure that if I link a bunch of objects together using -Bshareable, then ld(1) will generate a symbol table for me. The objects don't have to contain PIC code for this. You can do this with non-PIC objects for userland shared libraries but the text relocations make this wasteful of memory. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891