This is the mail archive of the 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] Fix static-binary lazy FPU context allocation

On Thu, 22 Aug 2013, Rich Felker wrote:

> > > >  We have an issue with FPU control word initialization in static binaries.  
> > > > We do it unconditionally, defeating any lazy FPU context allocation the OS 
> > > > may implement.
> > > 
> > > Could you elaborate on why this initialization needs to take place at
> > > all? Under what conditions would the kernel give an incorrect initial
> > > control word?
> > 
> >  There's no "incorrect" control word.  There's one kernel default for each 
> > particular target (and possibly ABI variation on that target).  Our 
> > default value of __fpu_control is meant to match the kernel default so if 
> > we use it -- fine.
> My view is that any value that gives anything other than correct
> IEEE/Annex-F conforming behavior is an incorrect control word. Anyway,
> would it be correct to state that this whole issue is only relevant
> when the application is using the (undocumented?) feature of
> overriding the initial control word by defining its own __fpu_control
> symbol?

 No it would not.  The pessimisation triggers for the default case, not 
the case where __fpu_control has been overridden.  If you think that this 
whole functionality is invalid, then please contribute a change that 
removes it.  Until such a change has been accepted I see no reason why the 
static case should be pessimised compared to the dynamic case now that we 
have auxiliary vector handling in static startup as well.


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