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


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