This is an archive of the discontinued LLVM Phabricator instance.

[lld] [ELF] Implement --export-dynamic/-E
ClosedPublic

Authored by rafaelauler on Oct 2 2014, 12:22 PM.

Details

Summary

When creating a dynamic executable and receiving the -E flag, the linker should
export all globally visible symbols in its dynamic symbol table.

Diff Detail

Event Timeline

rafaelauler retitled this revision from to [lld] [ELF] Implement --export-dynamic/-E.
rafaelauler updated this object.
rafaelauler edited the test plan for this revision. (Show Details)
rafaelauler added reviewers: Bigcheese, shankarke.
rafaelauler added subscribers: Unknown Object (MLST), rafael.
emaste added a subscriber: emaste.Oct 2 2014, 12:53 PM
shankarke added inline comments.Oct 2 2014, 12:57 PM
include/lld/ReaderWriter/ELFLinkingContext.h
162

should be applicable even for buiding shared libraries (ET_DYN) as well.

lib/Driver/GnuLdOptions.td
83–88

Can you move this under dynamic library and executable options ?

lib/ReaderWriter/ELF/OutputELFWriter.h
187

should we change the dynamicExport for all atoms, when dynamic export is set, to be dynamicExportAlways ? What do you think ?

Hi Shankar,

Thanks for putting in time to review this patch. Comments below.

include/lld/ReaderWriter/ELFLinkingContext.h
162

I'm somewhat confused because I based this patch on what GNU ld manual says:

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

Can you confirm that this should work for shared libraries as well? If so, what is the effect, since shared libraries already export all symbols by default?

lib/ReaderWriter/ELF/OutputELFWriter.h
187

Indeed I think It would be a cleaner solution, I'll look into this.

shankarke added inline comments.Oct 2 2014, 1:54 PM
include/lld/ReaderWriter/ELFLinkingContext.h
162

--dynamic-list would alter this behavior, which is applicable for building shared libraries and dynamic executables.

rafaelauler updated this revision to Diff 14571.Oct 8 2014, 6:52 AM

I updated this patch according to suggestions. While this patch doesn't implement the effect of --export-dynamic when building shared libraries (currently, DynamicLibraryWriter already exports all symbols), it doesn't restrict the flag only to executables. I also moved the logic that exports symbols in the dynamic symbol table from OutputELFWriter to the ExecutableWriter class. I think it is not correct to leave this at OutputELFWriter because DynamicLibraryWriter, another subclass of OutputELFWriter, already exports all symbols, meaning we can potentially end up with duplicated symbols in the dynamic symbol table when creating shared libs.

Another aspect worth commenting is implementing --export-dynamic by making all ELF symbols to have the dynamicExportAlways propriety. I made a patch for this, but it required changing too many interfaces just to allow the "--export-dynamic" information to reach the ELFFile class, since it is loosely coupled via the Registry. The advantages would be to have exposed during the entire linking process that this symbol will be exported. After checking whether the dynamicExportAlways propriety is actually used during linking, I found out that it is not important, except when actually building the symbol table.

Therefore, I concluded that it was not worth the change and that we end up with simpler code if we just stick with checks for --export-dynamic when building the symbol table. If you think that we should change dynamicExportAlways, though, I can submit the other patch.

shankarke accepted this revision.Oct 8 2014, 8:29 AM
shankarke edited edge metadata.
This revision is now accepted and ready to land.Oct 8 2014, 8:29 AM
rafaelauler closed this revision.Oct 8 2014, 12:04 PM

Committed r219334.