This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Fix static-binary lazy FPU context allocation
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: <libc-alpha at sourceware dot org>
- Date: Fri, 23 Aug 2013 12:27:47 +0100
- Subject: Re: [PATCH] Fix static-binary lazy FPU context allocation
- References: <alpine dot DEB dot 1 dot 10 dot 1308221904520 dot 8514 at tp dot orcam dot me dot uk> <20130822211407 dot GJ20515 at brightrain dot aerifal dot cx> <alpine dot DEB dot 1 dot 10 dot 1308222302050 dot 8514 at tp dot orcam dot me dot uk> <20130822225301 dot GK20515 at brightrain dot aerifal dot cx>
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
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.