[llvm-dev] Linker visibility merging for weak and strong symbols

[Shoaib Meenai via llvm-dev]

Hi all,

We ran into an interesting visibility merging issue internally. We have a static library libA that’s built with RTTI and exceptions, and defines and exports a class Foo and has a key function for it (and therefore also defines the typeinfo for class Foo with default visibility). We have another static library libB that’s built with exceptions but without RTTI, and throws and catches objects of type Foo. Because libB is built without RTTI, the compiler generates a weak symbol for the typeinfo for Foo (instead of assuming that the key function means the typeinfo would be provided externally). libB is also built with hidden visibility, so this weak typeinfo for Foo symbol also gets hidden visibility. Finally, libA and libB are linked into the same shared library. LLD sets the visibility of a symbol to the lowest visibility of any instance of that symbol (https://github.com/llvm/llvm-project/blob/64a5e57a61bb6f6080236bd1e21afdf044ae810a/lld/ELF/Symbols.cpp#L386), so the typeinfo for class Foo ends up with hidden visibility, which means references to it from other shared libraries can’t be resolved and cause link errors.

I believe the proper solution here would be to compile libB with both exceptions and RTTI (and in general I think enabling exceptions but not enabling RTTI is a pretty big footgun, and I’d be supportive of a compiler option to flag that). However, one of my coworkers suggested that LLD should take weak vs. strong symbols into account when merging visibilities. The proposal is that a weak definition’s visibility shouldn’t be able to reduce the final symbol’s visibility below that of the lowest strong symbol definition. In this situation, since the strong definition of the typeinfo for Foo has default visibility and the weak definition has hidden visibility, the final symbol would have default visibility. (On the other hand, if both definitions were strong or both were weak, the final symbol would have hidden visibility.) I’m not familiar enough with visibility and visibility merging to have a good sense of the upsides and downsides of this proposal, so I figured I’d sent it to the list to see what people thought!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200319/12bb53d3/attachment.html>