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

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Fri, Mar 6, 2015 at 4:15 PM, Alan Modra <amodra@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 <amodra@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.