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] |
On 09 Aug 2015 14:24, Zack Weinberg wrote: > Is an IFUNC's variant-selecting function called only once per process, > or every time? it's once-per-process. if it were every time, it'd defeat the point of the optimization. > If we sent libc.so-internal calls to 'memset' through the PLT (as is > currently done for 'malloc') would that mean they were subject to IFUNC > dispatch? it's a double edge sword. we specifically want to avoid the PLT for two reasons: (1) speed (PLT is slow) (2) interposition (we don't want someone exporting a memset symbol and then internal glibc code calling that instead of our own version) we could create an internal symbol using the GLIBC_PRIVATE namespace which would solve (2), but we'd still be left with (1). and it's really hard to quantify the speed tradeoffs between using the PLT everywhere and the choice of two different mem/str funcs (e.g. SSE vs AVX). at least on older cpus where only SSE2 is available, we know there will be no speed increase, but there will be a speed loss (but still hard to quantify). > Is there any *other* way (that already exists - nothing that would > require binutils changes) to cause libc.so-internal calls to 'memset' to > be subject to IFUNC dispatch? Compared to using the PLT, what are the > costs and benefits of doing it that way? since IFUNC only exists to handle the PLT slot, doing IFUNC w/out PLT fundamentally doesn't make sense. -mike
Attachment:
signature.asc
Description: Digital signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |