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: [PATCH 0/2] Multiarch hooks for memcpy variants

On Tue, Aug 15, 2017 at 5:40 PM, Wilco Dijkstra <> wrote:
> Zack Weinberg wrote:
>> On Mon, Aug 14, 2017 at 9:22 AM, Wilco Dijkstra <> 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 so we are stuck with them, but
>> what if we demote the copies in 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?


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