This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] x86-64: Implement strcat family IFUNC selectors in C
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 15 Jun 2017 14:20:57 -0300
- Subject: Re: [PATCH] x86-64: Implement strcat family IFUNC selectors in C
- Authentication-results: sourceware.org; auth=none
- References: <20170612161054.GD25262@gmail.com> <3c3aa55b-309d-c024-df3f-cd61fa2826c6@linaro.org> <CAMe9rOq3gUF3LCt1rmSo5GsLv7FPk5PPisYn1fQVH+py=n2MAA@mail.gmail.com>
On 15/06/2017 12:51, H.J. Lu wrote:
> On Thu, Jun 15, 2017 at 8:32 AM, Adhemerval Zanella
> <adhemerval.zanella@linaro.org> wrote:
>>
>>
>> On 12/06/2017 13:10, H.J. Lu wrote:
>>> Implement strcat family IFUNC selectors in C.
>>>
>>> All internal calls within libc.so can use IFUNC on x86-64 since unlike
>>> x86, x86-64 supports PC-relative addressing to access the GOT entry so
>>> that it can call via PLT without using an extra register. For libc.a,
>>> we can't use IFUNC for functions which are called before IFUNC has been
>>> initialized. Use IFUNC internally reduces the icache footprint since
>>> libc.so and other codes in the process use the same implementations.
>>> This patch uses IFUNC for strcat family functions within libc.
>>>
>>> Any comments?
>>>
>>> H.J.
>>> * sysdeps/x86_64/multiarch/Makefile (sysdep_routines): Add
>>> strcat-sse2.
>>> * sysdeps/x86_64/multiarch/strcat-sse2.S: New file.
>>> * sysdeps/x86_64/multiarch/strcat.c: Likewise.
>>> * sysdeps/x86_64/multiarch/strncat.c: Likewise.
>>> * sysdeps/x86_64/multiarch/strcat.S: Removed.
>>> * sysdeps/x86_64/multiarch/strncat.S: Likewise.
>>
>> LGTM, but since the idea is to use IFUNC for internal symbol call, do we
>> still need the assembly implementation for x86_64? Default algorithm should
>> be good enough with both vectorized strlen and strcpy (same for strncat)
>
> That will be a separate patch. We will look into these for 2.27.
>
> Thanks.
>
Fair enough then.