This is the mail archive of the
mailing list for the binutils project.
Re: Make __start/__stop symbols protected visibility
On Tue, 22 Aug 2017, H.J. Lu wrote:
> On Tue, Aug 22, 2017 at 1:04 AM, Alan Modra <firstname.lastname@example.org> wrote:
> > On Mon, Aug 21, 2017 at 05:29:14AM -0700, H.J. Lu wrote:
> >> When SYMBOLIC_BIND is set, protected visibility no longer make any
> >> senses.
> > I already explained why __start_section and __stop_section symbols
> > ought to be protected visibility. You want a symbol that is visible
> > to other modules but resolves locally. That is exactly what the gABI
> > says of protected visibility.
> > STV_PROTECTED
> > A symbol defined in the current component is protected if it is
> > visible in other components but not preemptable..
> > So by making these linker defined symbols protected visibility, the
> > object itself documents their binding.
> STV_PROTECTED is meaningful only if there is a dynamic relocation.
> When the relocation is already resolved by the linker at run-time via
> SYMBOLIC_BIND, the symbol is not preemptable regardless if it is
> STV_PROTECTED or not.
The symbolic_bind hack is only necessary because protected symbols are
broken on x86 and not usable for what they are intended. In a better
world it wouldn't be needed, and protected visibility would then be
enough, and indeed the right thing.
In that better world there never would be dynamic relocs against a
PROTECTED symbol, because they always would have been resolved
locally/transformed into RELATIVE. Such symbols could then indeed
conceivably be made GLOBAL in the final shared object, but why would that
be better? Leaving them PROTECTED also in the exported symbols makes