From owner-freebsd-hackers Tue Feb 16 15:15:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 7E19E10F64 for ; Tue, 16 Feb 1999 15:15:25 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id QAA10939; Tue, 16 Feb 1999 16:15:14 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpd010870; Tue Feb 16 16:15:10 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id QAA09820; Tue, 16 Feb 1999 16:14:59 -0700 (MST) From: Terry Lambert Message-Id: <199902162314.QAA09820@usr08.primenet.com> Subject: Re: symbol export question To: kbyanc@freedomnet.com (Kelly Yancey) Date: Tue, 16 Feb 1999 23:14:59 +0000 (GMT) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <000201be59e3$0ebbf5c0$1468f0c6@tech.freedomnet.com> from "Kelly Yancey" at Feb 16, 99 02:32:15 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > So the question is: what is the proper way to export symbols from an > executable so that dynamicly loaded libraries can access just those symbols > (not all symbols in the executable)? Presumably the same holds true for > building libraries which don't export all of their symbols. % man ld [ ... ] -export-dynamic When creating an ELF file, add all symbols to the dynamic symbol table. Normally, the dynamic symbol table contains only symbols which are used by a dy- namic object. This option is needed for some uses of dlopen. [ ... ] You might also want to look at the info file for gld, since the man page is seriously out of date, and there don't appear to be FreeBSD people who think that updating such things is cool (there needs to be a technical writer on the core team, and some university English department need to become sucked into^W^Winvolved with FreeBSD). See: --retain-symbols-file FILE Keep only symbols listed in FILE And: -Map FILE Write a map file Or: -f SHLIB, --auxiliary SHLIB Auxiliary filter for shared object symbol table -F SHLIB, --filter SHLIB Filter for shared object symbol table > Oh, and on a related note: the man page for dlopen() indicates that dlopen > invokes _init() and dlclose() invokes _fini() in the dynamic library. My own > testing indicates that while this is true, the standard C library implements > _init() which calls main() (presumably all programs are actually started my > calling _init() which the standard library handles and in turn calls the > familiar main() ...for C at least). I suppose the standard library also > intercepts _fini() and performs cleanup too. I found that I can get around > the preprocessing by passing -nostdlib to gcc and implementing _init() and > _fini() in the libraries myself. Is this advisable? What kind of cleanup > could the standard library possibly be doing in _fini() and is there any > other way for me to hook into to _fini() operation? This is not correct behaviour. What's supposed to happen is that all symbols in the .init and .fini *ELF sections* are supposed to be call on startup and shutdown. The C++ compiler *happens* to aggregate them into these particular functions in each of these sections, but it's not a hard requirement. As it is, you would not be able to use ld -r on an image linked shared to a library containing constructors. This is actually a deviation from the ELF specification (the IABI) and has been discussed in detail before, when someone tried to rename the functions to begin with dots "like the spec says" (sic). The code works because the _init/_fini are the first things in the respective .init/.fini sections. But the direct calls are actually *wrong*. > I'de like to be able to dynamically add (or occasionally) remove the > libraries from my process's address space and I need a way for the library > to know when it is getting unloaded so that it can restore and vectors in > the main executable it hooked. I suppose I could implement my own function > in each library which the process calls before dlclose()ing it, but it just > seems so nice to be able to use the function already provided for that > purpose. You are supposed to attribute the object/region so that it is put in the correct section. There is an undocumented linker option that can be used on a per object file basis (see the ld source code for details on usage; the one Makefile I built that depends on this is at home). There is also support for using "#pragma section(some_name)", I believe, but it may only exist in the Cygnus version of the compiler, or even only in the WIN32 specific version of the Cygnus compiler, since it's used in that environment to enable compilation of VXD's (Windows drivers). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message