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. > 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 it work. -- H.J.
