RE: stable binutils, gcc, glibc ...

["Jay Carlson" <nop@nop.com>]

Ralf Baechle [mailto:ralf@oss.sgi.com] writes:

> > Does anyone know if gcc 2.97 can build glibc 2.0.x?
>
> As I already wrote in my other email this seems to work.  However there is
> a little minefiled hidden there which I should warn you about.  Sometimes
> gcc emits references to __register_frame_info which is a libgcc defined
> symbol.  This function happened to be defined coincidntally in libtermcap
> and a few others such that these references so far usually were satisfied.
> Now built with gcc 2.97 libtermcap no longer defines this symbol and so a
> few programs like for example mutt2 or bash2 will die therefore.

Ah yes, this has bit me a few times even with my hacked 2.95.2.  I think
this is what the libc-hacker people were talking about in terms of glibc
mistakenly reexporting the exception handing stuff.  I don't remember them
being very happy about it.

> > For the record, the glibc patch does two things:
> >
> > 1) longjmp/setjmp will only save FPU registers if __HAVE_FPU__
> is defined.
> > In unmodified egcs 1.0.3a, "%{!msoft-float: -D__HAVE_FPU__ }".
> >
> > 2) conditionalizes _FPU_GETCW and _FPU_SETCW in fpu_control.h.
> If I recall
> > correctly, _FPU_SETCW() is called early in program startup, even for
> > programs that will never touch the FPU.  This of course causes
> instant death
> > unless the kernel can emulate "ctc1 foo,$31"....
>
> I would prefer to see that this patch using some mechanism which detects
> the precense / absence of hardware fp at runtime and behaves accordingly.

I don't think this is necessary for any correctly built and linked
executable.

On platforms with no hardware FPU and no kernel emulation, any main program
or library trying to touch a floating point variable will immediately bomb,
so there is no chance of undiagnosed incorrect behavior.

On machines with FPUs, setjmp/longjmp between modules that disagree on
__HAVE_FPU__ will result in the callee-saved FPU registers not being
saved/restored properly, and that will be a silent failure.  On the other
hand, any intercall between modules where a float as an argument or return
value will silently fail too.

The most plausible failure case I can think of is on a machine with
hardware/kernel FPU.  A softfloat main program calls some kind of hardfloat
plugin .so, solely using integer arguments/return values.  However, the
plugin was built hardfp, and gets upset when the FP control word isn't
initialized...

I dunno.  I just don't see softfp binaries ever showing up on hardfp
platforms, aside from the proposed Linux VR transition to hardfp.

Jay