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:52 AM, Michael Matz <firstname.lastname@example.org> wrote:
> On Wed, 23 Aug 2017, H.J. Lu wrote:
>> >> 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.
> Yes, and the fix is to not do copy relocs for protected symbols, instead
> of breaking the reason d'etre for protected visibility.
I added GNU_PROPERTY_NO_COPY_ON_PROTECTED to GNU
program property. Compiler can generate reference via GOT and set
GNU_PROPERTY_NO_COPY_ON_PROTECTED. This reminds me
to update linker to check GNU_PROPERTY_NO_COPY_ON_PROTECTED.
>> > 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.
> As we discussed on various times at considerable length, pointer equality
> simply needs to be given up for protected symbols, when copy relocations
> are involved. Alternatively copy relocations of protected symbols need to
> be avoided, at the expense of different code generation inside
> executables. With people using PIE more and more the latter part is
> already on the way, no copy relocs --> pointer equality works naturally.
By default, PIE will use copy relocation. We can turn it off and set