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] Save fp registers on x64 function resolution.


On Fri, Jul 26, 2013 at 04:54:38PM +0000, Joseph S. Myers wrote:
> On Fri, 26 Jul 2013, Ondrej Bilka wrote:
> 
> > Hi, as having to manually save xmm registers causes many issues recently
> > (memset issues, bug 15786...) this patch save xmm registers. If you
> > accept it to 2.19 further cleanups will follow. 
> > 
> > We could also add register saving for other architectures.
> 
> Could you please give a proper self-contained explanation of what the 
> issue is so that architecture maintainers can tell whether it is relevant 
> to their architecture or not?
> 
There are at least three issues with it.

First is that it places unnecessary burden to writers of IFUNCS.

Second is that it makes maintenance harder (as we seen in 
tree-loop-distribute-patterns).

Third are performance reasons as code that can not use vector registers
is slower than code that can and gcc options cause us to generate
suboptimal code in dynamic linker.

> For example, if the issue is that IFUNC resolvers may clobber 
> call-clobbered registers also used for passing arguments, and the fix 
> requirement is that on all IFUNC-supporting architectures the dynamic 
> linker must save and restore those registers around calls to the IFUNC 
> resolvers (or, as here, around a call to _dl_fixup), why isn't it 
> generically an issue for all C code in the dynamic linker, not just for 
> IFUNC resolvers?  Shouldn't it always be the case, on all architectures, 
> that call-clobbered registers used for passing arguments need to be saved 
> and restored around dynamic linker entry points
They should but historically we decided to avoid some registers on some
architectures. You can use  find | grep rtld- to see where.
> (not just in 
> _dl_runtime_resolve but also in _dl_runtime_profile around calls to 
> _dl_profile_fixup, and in dl-tlsdesc.S around calls to the TLS descriptor 
> lazy resolver functions)?
Code duplication. A _dl_runtime_profile used separate logic to save
registers and I did not expect that dl-tlsdesc.S duplicates dl_fixup logic.

As dl-tlsdesc is present only on x64 and arm, aarch64 it looks like
exceptional case

I did not consider avx in my patch. Easiest way to detect avx would be
ifunc-like way but it may cause problems. Probably I will add branch to
check it.


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