This is the mail archive of the
mailing list for the glibc project.
Re: RFC: SH4 and the __fpscr_values object
- From: "H. J. Lu" <hjl at lucon dot org>
- To: libc-alpha at sources dot redhat dot com
- Date: Tue, 6 May 2003 22:18:34 -0700
- Subject: Re: RFC: SH4 and the __fpscr_values object
- References: <20030507030206.GA24472@nevyn.them.org>
On Tue, May 06, 2003 at 11:02:06PM -0400, Daniel Jacobowitz wrote:
> Due to the way that the SH4 FPU operates, we have to save two values for the
> control register (one for single precision and one for double precision) in
> a global state so that we can switch between single and double precision
> operation without losing changes to the fpscr state. That's my memory of
> how it works, anyway.
> What it boils down to is that any application which uses the FPU needs to
> have a copy of __fpscr_values, and it's important that there be exactly one
> copy in the application; including all loaded libraries.
> For a while this was implemented by having it in crti.o; it's since moved to
> crt1.o (don't know exactly why). The problem is that there's now an
> undefined reference in libm to __fpscr_values, and we build libm using -z
> So, any ideas on the right way to solve this problem? Is there some reason
> I'm missing that it can't just be a normal variable in libc6? That won't
> fix any libraries which build with -z defs but don't link to -lc, but I
> don't think there are many examples of that.
Why not declare it extern weak and make sure it is exported dynamically