Movatterモバイル変換
[0]ホーム
This is the mail archive of thelibc-alpha@sourceware.orgmailing list for theglibc 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> indefinitely.Not so; the libc_nonshared.a versions would call only the normal entrypoints plus __fortify_fail (I think that's what it's called). Thesymbols in libc_nonshared.a can themselves go away whenever theybecome unnecessary.Also, "have to provide non-compat _chk entry points indefinitely" isnot significantly worse than "have to provide compat _chk entry pointsindefinitely", and no matter what we do here we have to provide atleast 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 thecomplexity 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
[8]ページ先頭