[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

[Nick Kledzik]

On Dec 10, 2012, at 11:18 AM, Rafael Espíndola wrote:

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

Yes.  Adding a new function to libLTO also means rev-locking issues
between the linker and libLTO.   The linker already knows how to
always export globals for dylibs, so as Rafael says, the linker should
just interpret -export_dynamic to mean pretend a dylib is being created.

-Nick