Strange FPU/threads problem

Strange FPU/threads problem

[David Given]

Context: PowerMac 8200/120, 601 processor, stock kernel 2.4.12, libc 2.2.4,
gcc 2.95.4, Debian woodyish.

I'm finding something really weird is going on with my program. It works like
this:

I can compile the program either to use threads, or not to use threads. If I
compile it so it *doesn't* use threads, it works fine.

However, if I compile it so that it *does* use threads, it bails with a
SIGFPE the first time in encounters a floating point instruction. And I don't
know why.

What's happening is that my code is shuffling long longs around, and gcc is
using the FPU as a fast way of doing this. The exact code is:

    C81F0008 0FE24468 lfd f0, 8 (r31)
    D81F0028 0FE2446C stfd f0, 40 (r31)

I've determined that the code is being executed in the primary process; that
is, it hasn't spawned any threads yet. The memory that's being pointed to is
valid.

The FP bit in the MSR is unset, so the processor thinks I'm not using the
FPU. But this should be perfectly normal, as my understanding of the kernel
suggests that it uses lazy FP setting. The kernel should hook the trap and
silently enable the FPU for me. But it's not.

I suspect that this may be a kernel bug. Any ideas?

--
David Given
dg@tao-group.com

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Strange FPU/threads problem

[David Given]

On Tuesday 20 November 2001 18:16, David Given wrote:
[...]
> However, if I compile it so that it *does* use threads, it bails with a
> SIGFPE the first time in encounters a floating point instruction. And I
> don't know why.
[...]

I've done some more research. The thing that's causing the exception is
arch/ppc/kernel/traps.c+291 (for Linux version 2.4.15), claiming an IEEE FP
exception. The relevant code is:

        if (regs->msr & 0x100000) {
                /* IEEE FP exception */
                _exception(SIGFPE, regs);
        }

Now, my copy of the 601 manual claims that only bits 27 to 16 of the MSR are
defined, which translates to bits 5 to 15 in the real world, because the 601
manual numbers the bits the wrong way round throughout[1]. Which means that
bit 20, above, is undefined. MSR turns out to be:

	00010F930

What *is* that bit 20? According to the MSR, the FPU is enabled, FE0=FE1=1
(precise mode)... could the processor be generating the exception because the
thing being loading into the FPU isn't a valid double? In which case, how
come my code works when threads are disabled?

I could really use some help here.


[1] DIE DIE DIE

--
David Given
dg@tao-group.com

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Strange FPU/threads problem

[Gabriel Paubert]

On Fri, 23 Nov 2001, David Given wrote:

>
> On Tuesday 20 November 2001 18:16, David Given wrote:
> [...]
> > However, if I compile it so that it *does* use threads, it bails with a
> > SIGFPE the first time in encounters a floating point instruction. And I
> > don't know why.
> [...]
>
> I've done some more research. The thing that's causing the exception is
> arch/ppc/kernel/traps.c+291 (for Linux version 2.4.15), claiming an IEEE FP
> exception. The relevant code is:
>
>         if (regs->msr & 0x100000) {
>                 /* IEEE FP exception */
>                 _exception(SIGFPE, regs);
>         }
>
> Now, my copy of the 601 manual claims that only bits 27 to 16 of the MSR are
> defined, which translates to bits 5 to 15 in the real world, because the 601
> manual numbers the bits the wrong way round throughout[1]. Which means that
> bit 20, above, is undefined. MSR turns out to be:
>
> 	00010F930
>

Besides disagreeing with your notion of bit order, I'd recommend you to
look at the section on exceptions, more precisely the table 5-16 "Program
Exceptions-Register settings" on page 5-33 if you have the same 601 doc as
me. SRR1 not only has a copy of the MSR, it also has a few bits whih
indicate the cause of the exception, unsurprisingly it says:

Bit 11: Set for a floating-point enabed program exception; otherwise
cleared.

I believe it is the same for all PPC processors and Power3/Power4.
This said, there have been recent patches wrt FPU handling in the kernel,
most notably clearing the FPSCR in some occasions.

	Regards,
	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/