Re: [PATCH 0/2] Multiarch hooks for memcpy variants

[Zack Weinberg <zackw at panix dot com>]

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

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
become unnecessary.

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?
You, perhaps?

zw