[PATCH] sunrpc: Remove hidden aliases for global data symbols [BZ #26210]

Carlos O'Donell carlos@redhat.com
Tue Jul 7 20:32:15 GMT 2020


On 7/7/20 4:04 PM, Florian Weimer wrote:
> * Carlos O'Donell:
> 
>> On 7/6/20 1:29 PM, Florian Weimer wrote:
>>> It is generally not possible to add hidden aliases for global data
>>> symbols: If the main executable contains a copy relocation against
>>> the symbol, the hidden aliases keep pointing to the glibc-internal
>>> copy of the symbol, instead of the symbol actually used by the
>>> application.
>>
>> Could there have been any way to catch this?
> 
> Code review?

I'm thinking more along the lines of a regression test that has a list
of things to check in this area and fails when you change that list
and then have to update it by hand which forces you to think about
this particular issue.

Similar to how we have local plt lists and tests.

>> Should we be adding tests to exercise all possible COPY relocations?
> 
> Or watch out for global data symbols without relocations against them.

Yes.

> But it's quite an obvious bug in retrospect.  _null_auth in the same
> file probably confused me—it's suspicious as well, but changing it after
> eleven years does not make much sense to me.

Sure.

>>> Fixes commit 89aacb513eb77549a29df2638913a0f8178cf3f5 ("sunrpc:
>>> Remove stray exports without --enable-obsolete-rpc [BZ #23166]").
>>>
>>> Tested on x86_64-linux-gnu, with and without --enable-obsolete-rpc.
>>> Manually checked for compat symbol status.
>>>
>>> Okay for glibc 2.32?
>>
>> OK for master.
>>
>> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
> 
> Thanks.
> 
> Florian
> 


-- 
Cheers,
Carlos.



More information about the Libc-alpha mailing list