This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH 0/2] Multiarch hooks for memcpy variants
On Tue, Aug 15, 2017 at 5:40 PM, Wilco Dijkstra <Wilco.Dijkstra@arm.com> wrote:
> Zack Weinberg wrote:
>> On Mon, Aug 14, 2017 at 9:22 AM, Wilco Dijkstra <Wilco.Dijkstra@arm.com> wrote:
>> > I still can't see any reason to even support these entry points in GLIBC, let
>> > alone optimize them using ifuncs.
>> They are already exported by libc.so.6 so we are stuck with them, but
>> what if we demote the copies in libc.so.6 to compat symbols and shove
>> the "real" versions into libc_nonshared.a? Then their calls to their
>> "normal" counterparts will naturally go through the PLT and hit the
>> "proper" ifuncs, without any messing around with assembly language.
> But that means we still need to provide non-compat _chk entry points
Not so; the libc_nonshared.a versions would call only the normal entry
points plus __fortify_fail (I think that's what it's called). The
symbols in libc_nonshared.a can themselves go away whenever they
Also, "have to provide non-compat _chk entry points indefinitely" is
not significantly worse than "have to provide compat _chk entry points
indefinitely", and no matter what we do here we have to provide at
least compat _chk entry points indefinitely.
> See below for an alternative option that removes them now [...]
I'm sorry, that seems an awful lot more complicated, and most of the
complexity is in the headers, which is the exact place I think it
_shouldn't_ be. And is anyone volunteering to do the compiler work?