Make __start/__stop symbols protected visibility

[H.J. Lu]

On Wed, Aug 23, 2017 at 7:42 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Tue, 22 Aug 2017, H.J. Lu wrote:
>
>> On Tue, Aug 22, 2017 at 1:04 AM, Alan Modra <amodra@gmail.com> 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

It is the direct result of copy relocation.

> 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

This is not true for pointers to protected functions.  Dynamic relocation
is needed for pointer equality.

> 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.
>
>
> Ciao,
> Michael.



-- 
H.J.