This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Fix static-binary lazy FPU context allocation
- From: Rich Felker <dalias at aerifal dot cx>
- To: "Maciej W. Rozycki" <macro at codesourcery dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 22 Aug 2013 18:53:01 -0400
- 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>
On Thu, Aug 22, 2013 at 11:36:10PM +0100, Maciej W. Rozycki wrote:
> 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?
Rich