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

Peter Collingbourne via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Nov 19 10:08:25 PST 2020


pcc added a comment.

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

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.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91583



More information about the llvm-commits mailing list