This is the mail archive of the gas2@sourceware.cygnus.com mailing list for the gas2 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: global vars and symbol visibility for mips32/elf


    That turns out not to be the case.  A shared library is not like an
    archive library.  A shared library is a single object.  Everything
    that composes a shared library is linked together.  There is only one
    set of symbols.  There is no way for the linker to form any sort of
    transitive closure operation, because there is no longer any
    distinction between the various object files which compose the shared
    library.

Although this may be how things work now, it is not really a useful
way for things to work.

Dividing an ordinary library into separate members provides two benefits:

* The members you don't refer to, do not take up space in your program.
* The members you don't refer to, do not fill up your program's name space.

The first benefit is not relevant or possible when using a shared
library, but the second is completely applicable.  Linking with a
shared library should give you exactly the same external symbols that
you would get by linking against the unshared library it was made
from.

Even if other people's shared library implementations don't do this
right, ours should do it right.

Doing this right does not require any changes in the shared library
run-time mechanism.  It only requires some way of representing, in the
shared library's symbol table, a division of external symbols into
various "library members".  Then ld can treat as weak any external
definitions which are not in the same "library members" as some symbol
that is referenced.  Each "library member" should have references as
well as definitions; that way, ld can tell that if "library member" A
is referenced, and it references member B, then the definitions in B
are not weak.

With an open-ended format such as ELF, it should not be hard to design
a way of representing this information, which does not conflict with
anything else and will not confuse other linkers.  If ld finds this
data, it should act accordingly; otherwise, it should do what it does
now.  That way, each of our tools is upward compatible.

This will make it possible to turn any unshared library into a shared
library, with no special precautions, and get no change in the
behavior except for sharing of memory.

Since ELF is the format that GNU systems use, it is not crucial to
implement this in formats other than ELF.

Would the people who work on ld please respond?