Re: stable binutils, gcc, glibc ...

[Ralf Baechle <ralf@oss.sgi.com>]

On Tue, Oct 17, 2000 at 09:59:49PM -0400, Jay Carlson wrote:

> 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.

It's FAQ.  In short their answer is to not use a newer compiler than
egcs 2.7.2 (or was it 2.8.1?).  Hardly acceptable for us.  Anyway, glibc 2.2
cleans up with that; a few programs need recompiling and where this is
not an option there is a small library that can be pre-loaded and which
will satisfy any references.

> > 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.

Ok.  Then we just need to make sure that people don't mix objects.

  Ralf