This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: PATCHES: Properly handle reference to protected data on x86

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 <> 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
> 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]