[PATCH] D91583: [lld] Allow --export-dynamic to override --lto-whole-program-visibility

Mon Nov 16 20:09:42 PST 2020

tejohnson added a comment.

In D91583#2398638 <https://reviews.llvm.org/D91583#2398638>, @MaskRay wrote:

> I'll need to study what whole program visibility does (e.g. I need to read http://lists.llvm.org/pipermail/llvm-dev/2019-December/137543.html "RFC: Safe Whole Program Devirtualization Enablement").
> My gut feeling is that: `--export-dynamic` is not sufficient to capture whether symbols are exported.
> When linking an executable,
>
> - Symbols matched by a `--dynamic-list` pattern are exported to the dynamic symbol table
> - Symbols matched by a `--export-dynamic-symbol` pattern exported to the dynamic symbol table
> - Symbols defined in the executable which are referenced by a shared object are exported.
>
> If the usage of `--export-dynamic` means whether the mode should apply to synthesized new symbols, I think having a mode referring to `--export-dynamic` makes sense.

Not just synthesized new symbols. It determines whether we can convert the LTO visibility of vtables to internal visibility. The intention was that it could be applied when you are doing static linking of a binary (without shared libraries on the link line). The problem is that --export-dynamic suggests that the binary might be intending to dlopen some shared libraries that weren't necessarily linked against. It is true that --export-dynamic-symbol and --dynamic-list can have this effect, but in a much more limited fashion. The goal is to be able to apply --lto-whole-program-visibility widely based on the linking mode, but then automatically disable it in situations where it is likely problematic.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91583