PERFORCE change 133911 for review

[Marcel Moolenaar]

On Jan 30, 2008, at 10:14 AM, Rafal Jaworowski wrote:

>>> 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 think it was libc. We eliminated fp{g|s}etmask and friends
from libc if I'm not mistaken.

> I also had a closer look at your import and it seems to me some  
> further work
> is required:

I know. I just imported it as-is. I need to glue it into the
FreeBSD sources.

-- 
Marcel Moolenaar
xcllnt at mac.com