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. -- Alan Modra Australia Development Lab, IBM