This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] x86-64: Implement strcpy family IFUNC selectors in C
- From: Zack Weinberg <zackw at panix dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Sun, 11 Jun 2017 10:31:31 -0400
- Subject: Re: [PATCH] x86-64: Implement strcpy family IFUNC selectors in C
- Authentication-results: sourceware.org; auth=none
- References: <20170611135042.GA22931@gmail.com> <email@example.com> <CAMe9rOrLqY-xK4x=uyMks45y5knhWdSrGL78FLDXJ7RmRknnSw@mail.gmail.com>
On 06/11/2017 10:21 AM, H.J. Lu wrote:
> On Sun, Jun 11, 2017 at 7:01 AM, Zack Weinberg <firstname.lastname@example.org> wrote:
>> On 06/11/2017 09:50 AM, H.J. Lu wrote:
>>> Implement strcpy family IFUNC selectors in C.
>>> All internal calls within libc.so can use IFUNC on x86-64 since unlike
>>> x86, x86-64 doesn't need to reserve a register to make a PLT call. 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.
>>> The patch uses IFUNC for strcpy family functions within libc.
>>> Any comments?
>> I like the idea, but I don't understand ifuncs nearly well enough to
>> comment on your code. I recall _strenuous_ objections to this concept
>> in the past; please post some performance numbers or something.
> I don't believe there is a benchmark where hot spots are within libc.so.
> BTW, if there are such benchmarks, I'd love to know.
> The main benefit is to reduce icache footprint at a price of an indirect
> branch via PLT.
Could you maybe produce numbers on the reduced icache footprint? perf
should be able to capture that...