PERFORCE change 133911 for review

[Rafal Jaworowski]

Hi Marcel,

>> IIRC, almost any AIM binary I tried executing caused FP exceptions
>> (actually,
>> an illegal instrusction ;) on e500, even such that wouldn't be
>> expected tu use
>> FPU. I didn't investigate this at all, but maybe the compiler was
>> using FPRs
>> for optimizations or something of that sort, don't know, so the frequency
>> might not be that low in reality.
> 
> We didn't see this at all. We typically only saw ntpdate
> and top crap out, because they actually use FP. Most of
> the binaries were fine without -softfloat.
> 
> Note also that a stray FP status register initialization
> operation in crtX can cause all processes to fail, even
> if there's no FP in the process. Your problem may have
> been caused by libc, crt or libgcc. In fact, we may have
> seen it ourselves as well and fixed that place to get to
> where we ended up without softfloat (i.e. only ntpdate,
> top, etc capping out).

Hm, yes, this could be it. Do you happen to recall the proximity of those
fixes/changes you have applied back then? It's nothing serious, I'm just
curious, maybe I'd give this another spin in free time (he, he).

I also had a closer look at your import and it seems to me some further work
is required: there are NetBSD definitions/macros missing, and from what I
could see bulk of the code is already in the tree: lib/libc/sparc64/fpu. It's
some older version than you've pulled in, and sparc64 is apparently using this
for libc connection (not sure if this is what Peter was referring to in one of
the previous emails?), but we probably should share this and not keep a
separate copy.

Rafal