RFC: SH4 and the __fpscr_values object
Daniel Jacobowitz
drow@mvista.com
Wed Jun 4 20:44:00 GMT 2003
On Tue, May 06, 2003 at 10:18:34PM -0700, H. J. Lu wrote:
> 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
> > defs.
> >
> > 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
> from crt1.o?
Because that would have the same problem we have now: crt1.o is not
included in libm and libm is linked using -z defs.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
More information about the Libc-alpha
mailing list