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

[Teresa Johnson via Phabricator via llvm-commits]

tejohnson added a comment.

In D91583#2406005 <https://reviews.llvm.org/D91583#2406005>, @pcc wrote:

> In D91583#2404678 <https://reviews.llvm.org/D91583#2404678>, @tejohnson wrote:
>
>> In D91583#2404519 <https://reviews.llvm.org/D91583#2404519>, @pcc wrote:
>>
>>> I've said before that I think that `--lto-whole-program-visibility` should relax visibility of vtable symbols etc to hidden. That way, `--export-dynamic` wouldn't actually allow you to make this kind of mistake.
>>
>> That would presumably result in an error in some of the problematic cases, whereas here we want to simply suppress --lto-whole-program-visibility to avoid any issues automatically.
>>
>> But isn't it the case that you don't even need for the vtable symbol itself to be exported in order to derive from the class and override its virtual methods?
>
> That's true, but it's the same situation that we have now with `--lto-whole-program-visibility` and not passing `--export-dynamic`.

Right, just confirming my understanding.

> I thought that `--lto-whole-program-visibility` was basically intended to do the same thing as specifying `__attribute__((visibility("hidden")))` on classes, except at link time. That isn't fundamentally incompatible with `--export-dynamic` (or, for that matter, `-shared`) since you can always expose an interface that doesn't involve the classes.

Correct. It's an assertion. The goal of --lto-whole-program-visibility was to apply it uniformly when the build system believes it is doing static linking, but in some occasional cases a binary may require --export-dynamic and it is simpler to automatically fall back to non-lto-whole-program-visibility in that case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91583