This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: RFC: SH4 and the __fpscr_values object
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: "H. J. Lu" <hjl at lucon dot org>, libc-alpha at sources dot redhat dot com
- Date: Wed, 4 Jun 2003 18:26:16 -0400
- Subject: Re: RFC: SH4 and the __fpscr_values object
- References: <20030507030206.GA24472@nevyn.them.org> <20030506221834.C16447@lucon.org> <20030604204434.GA22816@nevyn.them.org>
On Wed, Jun 04, 2003 at 04:44:35PM -0400, Daniel Jacobowitz wrote:
> 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.
Well, this is what I'm using. As long as you don't mess with the
visibility of __fpscr_values in either place, it appears to work fine.
(Oh, and the copy in crt* is obsolete with this patch and can be
removed.)
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
2003-06-04 Daniel Jacobowitz <drow@mvista.com>
* sysdeps/sh/sh4/Makefile: New file.
* sysdeps/sh/sh4/Versions: New file.
* sysdeps/sh/sh4/sh-fpscr: New file.
diff -Nurp glibc-2.2.3/sysdeps/sh/sh4/Makefile glibc-2.2.5/sysdeps/sh/sh4/Makefile
--- glibc-2.2.3/sysdeps/sh/sh4/Makefile 1969-12-31 19:00:00.000000000 -0500
+++ glibc-2.2.5/sysdeps/sh/sh4/Makefile 2002-09-16 19:20:22.000000000 -0400
@@ -0,0 +1,3 @@
+ifeq ($(subdir),misc)
+sysdep_routines += sh-fpscr
+endif
diff -Nurp glibc-2.2.3/sysdeps/sh/sh4/Versions glibc-2.2.5/sysdeps/sh/sh4/Versions
--- glibc-2.2.3/sysdeps/sh/sh4/Versions 1969-12-31 19:00:00.000000000 -0500
+++ glibc-2.2.5/sysdeps/sh/sh4/Versions 2002-09-16 19:20:22.000000000 -0400
@@ -0,0 +1,5 @@
+libc {
+ GLIBC_2.3.2 {
+ __fpscr_values;
+ }
+}
diff -Nurp glibc-2.2.3/sysdeps/sh/sh4/sh-fpscr.S glibc-2.2.5/sysdeps/sh/sh4/sh-fpscr.S
--- glibc-2.2.3/sysdeps/sh/sh4/sh-fpscr.S 1969-12-31 19:00:00.000000000 -0500
+++ glibc-2.2.5/sysdeps/sh/sh4/sh-fpscr.S 2002-09-16 19:32:02.000000000 -0400
@@ -0,0 +1,12 @@
+# Necessary for compatibility with older SH installations
+# This symbol was formerly in libgcc as a common (.comm) symbol
+# but it needed to be properly initialized, so it moved to crti.o.
+# crti.o is not linked into libc.so.6, so we need this patch to provide
+# a definition for older applications (which did not use FP themselves,
+# and thus did not bring in their own definition of __fpscr_values).
+ .data
+ .weak __fpscr_values
+ .global __fpscr_values
+__fpscr_values:
+ .long 0
+ .long 0x80000