On Fri, Mar 6, 2015 at 4:15 PM, Alan Modra <amo...@gmail.com> wrote: > On Fri, Mar 06, 2015 at 05:04:56AM -0800, H.J. Lu wrote: >> On Thu, Mar 5, 2015 at 8:19 PM, Alan Modra <amo...@gmail.com> 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 >> >> 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. >> >> I believe my new testcases on hjl/pr17711 branch at >> >> https://sourceware.org/git/?p=glibc.git;a=summary >> >> covers those and they work correctly. > > The test that I see in commit 9ea148bb does not. Please notice that > I'm asking you about two protected definitions in the libraries, not > one protected and one with default visibility.
My patch extends my work for protected function pointer to cover protected data. There is no reason why it shouldn't work. I updated the testcase to commit 88af4693bd32e3658206b73c121de9a36c510f6b Please check it out. -- H.J.
