This is the mail archive of the
mailing list for the glibc project.
Re: RFC: PATCHES: Properly handle reference to protected data on x86
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: GCC Patches <gcc-patches at gcc dot gnu dot org>, GNU C Library <libc-alpha at sourceware dot org>, Binutils <binutils at sourceware dot org>
- Date: Fri, 6 Mar 2015 05:04:56 -0800
- Subject: Re: RFC: PATCHES: Properly handle reference to protected data on x86
- Authentication-results: sourceware.org; auth=none
- References: <CAMe9rOoKS4BwBSd2T+bcchYOykZ7Gzh2jCMC5J6r0qyEX1u0_Q at mail dot gmail dot com> <20150306041931 dot GE25172 at bubble dot grove dot modra dot org>
On Thu, Mar 5, 2015 at 8:19 PM, Alan Modra <firstname.lastname@example.org> wrote:
> On Wed, Mar 04, 2015 at 03:26:10PM -0800, H.J. Lu wrote:
>> Protected symbol means that it can't be pre-emptied. It
>> doesn't mean its address won't be external. This is true
>> for pointer to protected function. With copy relocation,
>> address of protected data defined in the shared library may
>> also be external. We only know that for sure at run-time.
>> Here are patches for glibc, binutils and GCC to handle it
>> Any comments?
> I'd like to see this pass some more tests. For example
> reference in non-PIC exe to var x
> protected visibility definition of x in libA
> protected visibility definition of x in libB
> I suspect you don't have this case correct, but congratulations if you
> do! Assuming libA is first on the breadth first search for libraries,
> then exe and libA ought to use the same x, but libB have its own x.
I believe my new testcases on hjl/pr17711 branch at
covers those and they work correctly.
> In fact it would be good to prove that all variations of either a
> reference, a default visibility definition or a protected visibility
> definition worked in the exe plus two libs case.
You can git my branch a try on PPC. If PPC uses copy
relocation, it shouldn't be too hard to update PPC to make