This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Preventing preemption of 'protected' symbols in GNU ld 2.26
- From: Cary Coutant <ccoutant at gmail dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Joe Groff <jgroff at apple dot com>, Alan Modra <amodra at gmail dot com>, Binutils <binutils at sourceware dot org>
- Date: Tue, 29 Mar 2016 18:46:40 -0700
- Subject: Re: Preventing preemption of 'protected' symbols in GNU ld 2.26
- Authentication-results: sourceware.org; auth=none
- References: <AB592ABD-D6D7-4D2F-A0D6-45738F168DC4 at apple dot com> <BEDD88C6-7F80-45DA-9021-10587244AAE5 at apple dot com> <CAMe9rOq6rmvH458nufzfZnnU_=_n1yysbLzERNy-LWvEmjmN1A at mail dot gmail dot com> <983472E1-A1BC-4970-9CF9-0138A6BAD16D at apple dot com> <CAMe9rOqTTwirymAY6ORp6D_GnCsMc_hYEdy1NbZpG6x5vQc5DQ at mail dot gmail dot com> <6AAD87D2-90F9-4AD7-A195-AC91B76EA6AE at apple dot com> <CAMe9rOqNcYnm1YocG-m7XNDE0g68YQAGe=ULP-G98gaatpxSeA at mail dot gmail dot com>
>> However, protected doesn't work this way in older binutils, or with alternative tools like llvm or gold, and it sounds like protected was never intended to work this way either. Rather If gcc is interested in pursuing this optimization, it seems more responsible to me they could investigate introducing language-level annotations that let libraries opt into the optimization, instead of unilaterally breaking things for other binutils clients and introducing new complexity to get back to the original behavior.
>>
>
> Protected symbol never worked correctly on x86 before. My
> change closed a few long-standing bugs. There is no going-back.
You keep countering my arguments with assertions like, "it was a bug
and I fixed it," but you present no arguments of your own to support
your position. I'm not sure what long-standing bugs you're referring
to -- the only one I can find, PR target/65248 [1], was filed by you
yourself, so you can't really use that as support. In fact, PR
ld/15228 [2], was filed against ld for *not* refusing to make a COPY
relocation to a protected symbol, and Alan fixed that. Gold has the
same bug, and I intend to fix it there, too.
You have effectively made protected symbols "work" by disabling the
very thing they were designed to do. I don't know how to point out the
absurdity any more clearly.
<reductio ad absurdum>
By your logic, you should make GCC generate PIC code by default and
turn -fno-pic into a no-op, because non-PIC code doesn't "work" in a
shared library. (Ironically, that would actually make protected
symbols work again without your changes.) Over the years, I've heard
many complaints from developers that they couldn't put code into a
shared library without compiling it with a special option. When you
first heard that complaint, why wasn't your response to change the
compiler? Isn't that the only way to make shared libraries "work"?
</reductio ad absurdum>
-cary
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65248
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=15228