[llvm-commits] [llvm] r169656 - in /llvm/trunk: include/llvm-c/lto.h tools/lto/LTOCodeGenerator.cpp tools/lto/LTOCodeGenerator.h tools/lto/lto.cpp tools/lto/lto.exports

[Rafael Espíndola]

> Add the `lto_codegen_set_export_dynamic' function.
>
> This function sets the `_exportDynamic' ivar. When that's set, we export all
> symbols (e.g. we don't run the internalize pass). This is equivalent to the
> `--export-dynamic' linker flag in GNU land:
>
> --export-dynamic
>   When creating a dynamically linked executable, add all symbols to the dynamic
>   symbol table. The dynamic symbol table is the set of symbols which are visible
>   from dynamic objects at run time. If you do not use this option, the dynamic
>   symbol table will normally contain only those symbols which are referenced by
>   some dynamic object mentioned in the link. If you use dlopen to load a dynamic
>   object which needs to refer back to the symbols defined by the program, rather
>   than some other dynamic object, then you will probably need to use this option
>   when linking the program itself.
>
> The Darwin linker will support this via the `-export_dynamic' flag. We should
> modify clang to support this via the `-rdynamic' flag.

Close, but not exactly the same. The gnu ld manual doesn't correctly
say what "all symbols" means. In particular, it doesn't include hidden
functions, so those can be internalized.

For example, given

----------------------------------------
__attribute__((visibility("hidden"))) void foo(void) {
}
void bar(void) {
}
int main(int argc, char**argv) {
  return 0;
}
------------------------------------

We get:

$ clang -c test.c
$ clang  test.o -o t
$ readelf  -W --dyn-syms t  | grep 'foo\|bar'
$ clang  test.o -o t  -Wl,--export-dynamic
$ readelf  -W --dyn-syms t  | grep 'foo\|bar'
    15: 0000000000400770     1 FUNC    GLOBAL DEFAULT   12 bar

I.e., without -export-dynamic foo and bar are not in the dynamic
symbol table. With --export-dynamic only bar is.

I think a good summary of what --export-dynamic actually does is: for
symbol table computation, pretend we are creating a library, not an
executable.

Given that foo in the above example is not exported, LTO could still
internalize it, so I think lto_codegen_set_export_dynamic is more
restrictive than what it should be. The linker should just call
lto_codegen_add_must_preserve_symbol for bar and not for foo.

Cheers,
Rafael