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

Rafael Auler rafaelauler at gmail.com
Thu Oct 2 13:08:16 PDT 2014

Hi Shankar,

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

Comment at: include/lld/ReaderWriter/ELFLinkingContext.h:162
@@ +161,3 @@
+  bool shouldExportDynamic() const {
+    return _exportDynamic && _outputELFType == llvm::ELF::ET_EXEC;
+  }
shankarke wrote:
> should be applicable even for buiding shared libraries (ET_DYN) as well.
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?

Comment at: lib/ReaderWriter/ELF/OutputELFWriter.h:192
@@ +191,3 @@
+              da->scope() == Atom::Scope::scopeGlobal))
+          continue;
+        _dynamicSymbolTable->addSymbol(atom->_atom, section->ordinal(),
shankarke wrote:
> should we change the dynamicExport for all atoms, when dynamic export is set, to be dynamicExportAlways ? What do you think ?
Indeed I think It would be a cleaner solution, I'll look into this.


More information about the llvm-commits mailing list