Re: RFC: SH4 and the __fpscr_values object

[Daniel Jacobowitz <drow at mvista dot com>]

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