This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: RFC: PATCHES: Properly handle reference to protected data on x86
- From: Alan Modra <amodra at gmail dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: 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 14:49:31 +1030
- 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>
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
> properly.
>
> 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.
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.
--
Alan Modra
Australia Development Lab, IBM