Subject: Re: FPE (Re: 68LC040 FPE, PR #5133, UVM, and a security hole?)
To: Ken Nakata <kenn@synap.ne.jp>
From: Rolf Braun <rbraun@cstone.net>
List: port-mac68k
Date: 05/08/1998 10:57:20
>On Thu, 7 May 1998 16:06:56 -0400,
>rbraun@cstone.net (Rolf Braun) wrote:
>
>> I know, about last year I was discussing the hardware bug on the list with
>> Ken and some others. The workaround in that case is -msoft-float.
>
>I'd be surprised if it helped. But I've heard from someone it helped
>(someone in UK actually compiled the whole system with -msoft-float).
>Hmm... Why? Because NetBSD comes with libgcc2 routines necessary for
>-msoft-float, but they do use FPU instructions. That means, even if
>you compiled your whole system with -msoft-float, some FPU
>instructions would still be used.
Is this -msoft-float distribution available anywhere, or it is too old?
>Ah... Yes, *some* FPU instructions would still be used but FMOVEM
>would not be one of them. That can help.
>
>Side note: I'm converting FPE to use double as the internal floating
>point number representation (in order to reuse libm source), instead
>of Sparc FPE internal format (112-bit significand). But kernel won't
>compile without the soft-float routines mentioned above. And they
>have to be absolutely free of FPU instruction.
Hmm. Wait a minute, if the kernel has to be absolutely free of FPU
instructions, then how can you compile it if even -msoft-float generates
FPU instructions?
>> They're consistent in that they occur at relatively the same frequencies in
>> the same binaries. They don't always occur in the same place.
>
>That's puzzling me, too. I'm starting to suspect that there may be a
>problem in someplace other than FPE (a la the stack frame size bug
>found and fixed by Kelly Campbell).
>
>> If the bug was indeed fixed by Moto before Apple canned the 040, then I'd
>> expect that it is fixed in the 630 series, since that was one of the last
>> 040 models produced.
>
>However, I've seen an LC630 and an LC575 equipped with XC68LC040RC
>(the XC prefix denotes engineering samples)... The last 68k Macs
>equipped with the earliest LC040 chips.
>
>Although, IIRC, XC68LC040's don't have the F-line trap bug according
>to Steve Allen. The bug was made into a later mask revision when
>Motorola shrank the die size.
Oh? Hmm, maybe I'll open this thing up and see if it's an XC chip. Then I
know I don't have the bug. :))
>> >I doubt that vi and dt use the FPU/FPE at all. That would be why
>> >they're more stable than ls or ps (which do divisions, at least).
>>
>> I seem to remember that printf() uses FPU somehow...
>
>Yes, it does. Even if you call printf() with no floating point
>arguments, it does FMOVEM which seems to be causing the `random'
>segfaults. Vi and dt may have calls to printf(), but I can imagine
>they don't usually make the calls; Both programs are fairly screen
>oriented.
Hmm, maybe getting some float variables out of printf() would help?
>Anyway, I got a loaner LC575, thanks to Kazunori Miura and Kobunsha,
>and I'm actively working to fix FPE.
Cool. Thanks. :)
--
- Rolf Braun - rbraun@cstone.net - http://www.cstone.net/~rbraun/
- Sassy Software: cool software for your Macintosh or Apple IIgs
- Rolf's HTML & Stuff: creative web design for less
- Anyone attempting to post messages or send e-mail using my address
- without my permission will be held legally liable for forgery, and
- may be subject to legal action and severe legal penalties.