This is the mail archive of the libc-alpha@sourceware.org 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] Remove unnecessary IFUNC dispatch for __memset_chk.


On Sun, Aug 9, 2015 at 8:20 AM, Zack Weinberg <zackw@panix.com> wrote:
> On 08/09/2015 02:41 AM, Andreas Schwab wrote:
>> Zack Weinberg <zackw@panix.com> writes:
>>
>>> __memset_chk does a bounds check (which the C compiler will optimize
>>> just fine) and then calls memset.  That call will itself go through
>>> IFUNC dispatch,
>>
>> Does it?
>
> On further investigation it appears not to -- specifically, internal
> calls using __GI_foo appear to go straight to the default implementation
> of 'foo'.
>
> If so, I am inclined to think that that is a bug -- there are a *lot* of
> internal calls to memset and memcpy in libc, they should not miss out on
> architectural tuning.  I don't particularly understand how IFUNC works,
> but wouldn't it be sufficient to send internal calls to anything with an
> IFUNC through the PLT?  (I suppose there would then be a question of
> whether the architectural optimizations made up for the PLT overhead.)

Here is a description of IFUNC:

https://sites.google.com/site/x32abi/documents/ifunc.txt?attredirects=0&d=1

> I am also inclined to think that there is no good reason to gunk up the
> fortify implementation with IFUNCed _chk functions, regardless.  If
> losing out on architecturally tuned memory block functions is acceptable
> for normal calls inside libc, it should also be acceptable for fortified
> applications (which one *expects* to incur a cost).
>

The purpose of multiarch/memset_chk.S is to avoid one extra indirect
call via PLT.


-- 
H.J.


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