llvm dev - Mar 2020 - Linker visibility merging for weak and strong symbols

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>

Hello,

Reading the ELF spec on visibility in the latest version of the specification.
https://www.sco.com/developers/gabi/latest/ch4.symtab.html#visibility

There is an interesting line before the rules on merging visibility:
"
None of the visibility attributes affects resolution of symbols within an
executable or shared object during link-editing -- such resolution is controlled
by the binding type. Once the link-editor has chosen its resolution, these
attributes impose two requirements, both based on the fact that references in
the code being linked may have been optimized to take advantage of the
attributes.
"

Given the "Once the link-editor has chosen its resolution" which would
prefer the non-weak definition of S over the definition of S, then apply the
rules for combining visibility this would imply that we ignore the visibility of
the weak definition in favour of the non-weak definition.

My guess is that many linkers have not implemented it that way, instead choosing
the most restrictive visibility when processing the symbol.

If my reading is correct, then it will be worth raising PRs on the linkers that
get this wrong. LLD looks like one of them, the early version of ld.bfd I have
on my laptop also does but it could have been fixed in a later version.

As it will take some time for fixes to percolate through the ecosystem, it
would, as you say, be worth avoiding generating code with weak and non-weak
definitions where the weak definition has a more restrictive visibility.

Peter

________________________________________
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Shoaib
Meenai via llvm-dev <llvm-dev at lists.llvm.org>
Sent: 19 March 2020 01:55
To: llvm-dev at lists.llvm.org
Cc: Chris Sarbora
Subject: [llvm-dev] Linker visibility merging for weak and strong symbols

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!