Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Feb 1999 23:14:59 +0000 (GMT)
From:      Terry Lambert <>
To: (Kelly Yancey)
Cc:        freebsd-hackers@FreeBSD.ORG
Subject:   Re: symbol export question
Message-ID:  <>
In-Reply-To: <000201be59e3$0ebbf5c0$> from "Kelly Yancey" at Feb 16, 99 02:32:15 pm

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
>   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

[ ... ]

              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).


  --retain-symbols-file FILE  Keep only symbols listed in FILE


  -Map FILE                   Write a map file


  -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
Any opinions in this posting are my own and not those of my present
or previous employers.

To Unsubscribe: send mail to
with "unsubscribe freebsd-hackers" in the body of the message

Want to link to this message? Use this URL: <>