This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: SH4 and the __fpscr_values object


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]