Andreas Jaeger wrote:
>
> Jun Sun <jsun@mvista.com> writes:
>
> > Andreas Jaeger wrote:
> > >
> > > Jun Sun <jsun@mvista.com> writes:
> > >
> > > > Andreas Jaeger wrote:
> > > > >
> > > >
> > > > > > saves/restores the FP registers in setjmp/longjmp, the
> > > > >
> > > > > Any ideas how this can be done?
> > > > >
> > > > > > model of "simply sending SIGILL/SIGFPE" will result
> > > > > > in *all* processes being terminated with extreme prejudice,
> > > > > > starting with init!
> > > > >
> > > >
> > > > There is a patch for glibc2.0.7, which I think was done by Jay Carlson. It
> > > > basically works for glibc2.0.6 as well. See the one for glibc2.0.6 attached
> > > > below.
> > > >
> > > > I think the patch is not "clean", in the sense that you only want to apply it
> > > > if you want to configure with "--without-fp". Otherwise the patch will break
> > > > other configurations.
> > > >
> > > > Jun--- glibc-2.0.6/sysdeps/mips/__longjmp.c.orig-rpm Sat Sep 11 00:01:44 1999
> > > > +++ glibc-2.0.6/sysdeps/mips/__longjmp.c Sat Sep 11 00:02:36 1999
> > > > @@ -35,6 +35,7 @@
> > > > along the way. */
> > > > register int val asm ("a1");
> > > >
> > > > +#ifdef __HAVE_FPU__
> > >
> > > I looked through the whole of glibc and GCC and __HAVE_FPU__ is nowhere
> > > defined for MIPS. __HAVE_FPU__ is defined for m68k in GCC but that's
> > > the only platform.
> > >
> >
> > You are right - it is not defined in glibc. Instead it is defined in egcs.
> > For this particular build, I need to apply the mips patch for egcs 1.0.3a,
> > which supplies __HAVE_FPU__. You can find it somewhere on oss.sgi site.
> > There is an additional patch for softfloat which makes __HAVE_FPU__
> > conditional. See the attachement.
> >
> > > Therefore I don't think the patch makes any sense at all,
> >
> > Therefore, it does make sense. :-)
>
> As long as that old patch hasn't found it's way into the official
> sources, the patch doesn't make sense ;-). I'm willing to discuss
> these issues again after those or similar patches have been added to
> the CVS archive of GCC - but without this, there's no way to get the
> patches into glibc.
>
Well, like I said earlier. This is not a clean patch - it cannot be checked
in because it will break other configurations, AFAIK. (OK, I probably should
have called it *hack* from the beginning :-0)
It would be nice to have some clean solutions...
Jun
