This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Downgrade linker error on protected symbols in .dynbss to a warning
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Binutils <binutils at sourceware dot org>
- Date: Fri, 10 Apr 2015 05:49:05 -0700
- Subject: Re: Downgrade linker error on protected symbols in .dynbss to a warning
- Authentication-results: sourceware.org; auth=none
- References: <20150410094542 dot GL27812 at bubble dot grove dot modra dot org> <CAMe9rOq5nPMRZTm02feeWF1FY8FR7u1T5JGGzChzNM0mH-VHmQ at mail dot gmail dot com> <20150410115859 dot GM27812 at bubble dot grove dot modra dot org>
On Fri, Apr 10, 2015 at 4:58 AM, Alan Modra <amodra@gmail.com> wrote:
> On Fri, Apr 10, 2015 at 03:49:23AM -0700, H.J. Lu wrote:
>> Adding a warning is wrong since it is OK to have copy relocation against
>> protected symbol. It works with glibc 2.22.
>
> Not without gcc changes, and the gcc changes you posted will generate
> code that is wrong if using glibc 2.21. Somehow you even got your
GCC 5 is no more wrong than before with older glibc.
> changes past review into gcc-5! That's sad for gcc-5 on x86_64.
That is a matter of opinion.
>> Totally revert my patch is
>> also wrong as indicated by tests I added since protected symbols
>> should reference globally on targets with copy relocation. It will also fail
>> the new protected symbol tests in glibc.
>
> Please show me who approved your patch in the first place.
Since my patch is limited to x86, I thought it was OK.
> I'll OK a patch that leaves the warning enabled for previous gcc code
> but disables it when detecting code that is safe to use with .dynbss
> copies of protected visibility variables. Otherwise you are just
> hiding a real problem, as reported in PR15228. Exactly how you detect
> the safe code is up to you.
It was about the incorrect shared library with protected symbols and
it is a run-time issue. How can linker know if the run-time shared library
is safe at link-time?
The real problem on x86 in GCC and glibc has been fixed on x86.
I will re-install my patch which is limited to x86.
--
H.J.