Re: ld violating ELF specification for hidden symbols?

[Cary Coutant <ccoutant at google dot com>]

> Ah, yes, indeed. Having looked at a couple of arbitrarily chosen
> binaries that I know got linked with no special options, this only
> opens up the question of what determines whether a symbol
> makes it into .dynsym (I would have expected all of them to be
> there without telling the linker otherwise).

Normally, the linker would "export" (i.e., add them to the dynamic
symbol table) all global symbols that do not have hidden visibility.
This is normal and expected for shared libraries, but for executables,
that rule would export far more symbols than necessary, as shared
libraries make few direct calls into the executable. In order to
improve the dynamic linker's performance, then, the linker by default
exports only those symbols that are known to be referenced by the
shared libraries mentioned at link time. If the program uses dlopen(),
and the dynamically-loaded shared library may reference globals in the
main executable, those symbols must be exported. They may be exported
individually or en masse with the --export-dynamic option.

For completeness, there is one other reason why a symbol would be
placed in the dynamic symbol table: any symbol referenced by a dynamic
relocation must appear in the dynamic symbol table. If a local or
hidden symbol is referenced by a dynamic relocation, so you will see
that symbol, marked LOCAL, in the dynamic symbol table. A global
symbol not otherwise exported may also appear in the dynamic symbol
table for this reason.

All of this is more implementation detail than it is ABI, and I think
the ABI is purposefully vague on these issues.

-cary