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 09, 2015 at 11:09:20PM -0400, Mike Frysinger wrote:
> 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.
>

No, its once per each shared library.

 
> > 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)
>
No, as I wrote in 

[PATCH] x86-64: Remove plt bypassing of ifuncs. 

thats completely flawed analysis. In best case you could save few
cycles. As I looked on functions you would for most functions lose
at leat twenty cycles as differences between implementations are that
big.

But even best case is mistake. You completely forgotten cache effects
and for memset you maybe save few cycles but add kilobyte to instruction
cache footprint that causes more significant slowdown.

> > 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.


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