This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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 
intent clear.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]