This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Copy relocations against protected symbols
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Cary Coutant <ccoutant at google dot com>
- Cc: Binutils <binutils at sourceware dot org>
- Date: Thu, 18 Dec 2014 10:29:55 -0800
- Subject: Re: Copy relocations against protected symbols
- Authentication-results: sourceware.org; auth=none
- References: <20141212130509 dot GB23430 at bubble dot grove dot modra dot org> <CAMe9rOqmG2Qbn56kbndm3mZq5c5-fjdJs2mQNXj4GvzRTk3Ahw at mail dot gmail dot com> <20141215010749 dot GA8347 at bubble dot grove dot modra dot org> <CAMe9rOrT3Luw1TDi+Tw4Y=MEhe57wgxxzPNz+tNpp+HT_itBCg at mail dot gmail dot com> <20141218044500 dot GA23483 at bubble dot grove dot modra dot org> <CAHACq4pQgXT11kmG+BLcEdWKsE2t-V__i7dkprk_FRH0SEOYhw at mail dot gmail dot com>
On Thu, Dec 18, 2014 at 10:28 AM, Cary Coutant <ccoutant@google.com> wrote:
>> I doubt we'll find any clever solution. The linker defining a copy of
>> a variable in .dynbss is quite at odds with protected visibility. For
>> example, a protected visibility variable allows a compiler to generate
>> shared library code that accesses the variable without a GOT
>> indirection. However, it is exactly that GOT indirection that is
>> needed for ld.so to make the shared library use the .dynbss copy.
>
> Agreed. It looks like gold has the same problem; I'll commit a patch soon.
>
Should we simply disallow creating DSO with protected data on targets
with copy relocation?
--
H.J.