[PATCH] D91583: [LTO] Prevent devirtualization for symbols exported to dynamic linker

[Teresa Johnson via Phabricator via llvm-commits]

tejohnson added inline comments.


================
Comment at: lld/ELF/LTO.cpp:252
+    r.VisibleToDynamicLinker =
+        sym->isExportDynamic(sym->kind(), sym->visibility) ||
+        sym->inDynamicList;
----------------
MaskRay wrote:
> tejohnson wrote:
> > MaskRay wrote:
> > > `sym->exportDynamic || sym->inDynamicList`
> > > 
> > > Then `isExportDynamic` does not need to be public.
> > sym->exportDynamic is false for linkonce_odr vtables, that was what I was referencing in this comment (otherwise I could use includeInDynsym which checks that):
> > 
> > > Note that I couldn't use includeInDynsym in lld because that is not set for linkonce_odr symbols that were thus have canBeOmittedFromSymbolTable set (since any referencing module must have it's own copy) - we still want to block the LTO visibility upgrade for those symbols to avoid WPD. So I am using a slightly different interface that more directly checks whether export-dynamic is in effect.
> Sorry, I don't understand the difference. If I replace this with `sym->exportDynamic`, I don't get a test failure...
Ah, this is a test deficiency, looks like I need to make one or more of the vtables linkonce_odr to expose it. Will address that. The reason it is an issue for linkonce_odr can be seen in createBitcodeSymbol in lld/ELF/InputFiles.cpp, where it does:

    if (canOmitFromDynSym)
      newSym.exportDynamic = false;

The canOmitFromDynSym gets propagated via the input file but is originally set in GlobalValue::canBeOmittedFromSymbolTable() for linkonce_odr with hasAtLeastLocalUnnamedAddr().


================
Comment at: llvm/include/llvm/LTO/LTO.h:466
+  /// by a shared library not visible to the linker.
+  unsigned VisibleToDynamicLinker : 1;
+
----------------
MaskRay wrote:
> MaskRay wrote:
> > tejohnson wrote:
> > > MaskRay wrote:
> > > > How about VisibleToOtherModules?
> > > > 
> > > > The name VisibleToDynamicLinker is too tied to the ELF binary format.
> > > VisibleToOtherModules sounds to me like it means LLVM Modules that are being linked together statically. I wanted to note that these are symbols that may have dynamic references not seen by the static link. Is there anything like --export-dynamic for other binary formats? If not, then it is ELF specific anyway.
> > @rnk for thoughts on COFF.
> Perhaps another name is `Exported`.
> 
> For ELF, the does not seem to be restricted to shared objects seen as in the input file.
"Exported" is ambiguous - we use that throughout ThinLTO to mean exported from the current module (to other modules being LTO linked).

> For ELF, the does not seem to be restricted to shared objects seen as in the input file.

Sorry I don't follow?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D91583/new/

https://reviews.llvm.org/D91583