From owner-freebsd-hackers Sat Jan 6 09:36:41 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA05996 for hackers-outgoing; Sat, 6 Jan 1996 09:36:41 -0800 (PST) Received: from minnow.render.com (render.demon.co.uk [158.152.30.118]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA05985 Sat, 6 Jan 1996 09:36:34 -0800 (PST) Received: (from dfr@localhost) by minnow.render.com (8.6.12/8.6.9) id RAA12482; Sat, 6 Jan 1996 17:34:00 GMT Date: Sat, 6 Jan 1996 17:34:00 +0000 (GMT) From: Doug Rabson To: John Polstra cc: hasty@rah.star-gate.com, freebsd-hackers@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: Anyone got GNU `dld' ported to FreeBSD? In-Reply-To: <199601061632.IAA09570@austin.polstra.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG Precedence: bulk On Sat, 6 Jan 1996, John Polstra wrote: > Doug Rabson wrote: > > > It would be pretty easy in a static binary to 'demand load' ld.so > > the first time a dl*() function was used, I think. > > There's more to it than that. For instance, any useful library that > you're going to want to demand-load will almost certainly depend on some > functions in libc. When you demand-load something into a dynamically > linked executable (which we currently support), the library you're > loading will use the shared version of libc.so.x.x that is already present > in the executable's address space. But if the executable is static, > there is no way to link something new to its embedded, statically-linked > libc. (If the executable has been stripped, then the necessary symbols > aren't even there.) Furthermore, of course, not all of the modules > from libc.a will even be present in the executable -- only those that > were seen as necessary when the executable was built. > > It might be tempting to simply load in a new, shared copy of > libc.so.x.x when you do the dlopen. But that also wouldn't work > properly. Libc is not just functions; it's _shared_ data, too. For > example, data structures in the stdio package keep track of which files > are open, which buffers have data in them, etc. It doesn't work well to > have two independent copies of that stuff lying around. I think the right thing to do would be to have ld create a complete struct _dynamic for the application, with symbol tables. When it initialises ld.so, it supplies this table. When the app dlopens an object depending on libc.so, libc is mapped as usual (since it is not already loaded) but all the symbol lookups for libc symbols which happen to be linked into the main application would use the app's version by the normal rules. The downside of this is a larger static executable due to the extra symbol tables. Maybe have 3 classes of app: dynamic static but can use dl*() static -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 251 4411 FAX: +44 171 251 0939