This is the mail archive of the
mailing list for the binutils project.
Re: Make __start/__stop symbols protected visibility
On Wed, Aug 23, 2017 at 7:42 AM, Michael Matz <email@example.com> wrote:
> 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
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.