[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

[Bill Wendling]

On Dec 10, 2012, at 11:31 AM, Nick Kledzik <kledzik at apple.com> wrote:

> 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.
> 
Okay. Whatever you think is best in this situation. I can remove the `lto_codegen_set_export_dynamic' if that's what you want.

-bw