[PANIC] x87 FPU floating-point error

[Chain-Q]

Kernel Panic on x86_64 while building Free Pascal packages

I recently ported Free Pascal to Haiku/x86_64, but make all cannot complete, because during packages build (which is quite late in the build process) the kernel runs into panic. ​See this screenshot. Tried with R1/BETA1 and nightly (hrev52718), it's the same. It happens at various packages during the FPC build process, but always the same error and always at the packages build step.

To reproduce, check out FPC SVN trunk (revision 40793 or later), and using a bootstrap compiler binary (​available here) issue the following command in trunk/:

make all OVERRIDEVERSIONCHECK=1 PP=<path_to_bootstrap_compiler>

As host, i'm using VirtualBox 5.2.22 on macOS 10.14.2.

Note that the FPC port is still not complete, so it may contain bugs. Still it should not kill the kernel, I guess. The i386 port is not affected.

[Chain-Q]

KDL, R1/BETA1 x86_64 Free Pascal

[korli]

Seems to happen after ​https://github.com/haiku/haiku/blob/master/headers/private/kernel/arch/x86/64/cpu.h#L52

[mmlr]

This is reproducible under KVM configured with a single CPU. It is indeed the "fldcw" which happens to unmask some FPU exceptions. Register state at that point:

RAX=000000000000001c RBX=ffffffff801de220 RCX=00000000000003f8 RDX=0000000000000064
RSI=0000000000000400 RDI=ffffffff801da1e0 RBP=ffffffff8e0fd560 RSP=ffffffff8e0fd548
R8 =00000000000000d8 R9 =000000000000021c R10=00000000000000d8 R11=000000000000021c
R12=ffffffff801de220 R13=00000000ffffffff R14=0000000000000000 R15=ffffffff801da1e0
RIP=ffffffff80154f92 RFL=00003046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0000 00000000 000fffff 00000000
CS =0008 00000000 ffffffff 00a09900
SS =0010 00000000 ffffffff 00c09300
DS =0000 00000000 000fffff 00000000
FS =0000 ef720000 000fffff 00000000
GS =0000 90827110 000fffff 00000000
LDT=0000 00000000 0000ffff 00008200
TR =0030 801b1650 00000068 00008b00
GDT=     801eba40 0000062f
IDT=     801eaa40 00000fff
CR0=80010031 CR2=022da008 CR3=1c267000 CR4=000006a0
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000d01
FCW=1372 FSW=80a1 [ST=0] FTW=00 MXCSR=00001fa0
FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
FPR6=89705f4136b4a800 3fe1 FPR7=89705f4136b4a800 3fe1
XMM00=746978655f6461657268745f65676170 XMM01=00000000000000000000000000000000
XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000

Notice the FCW value of 0x1372 which means invalid operation, zero divide and overflow exceptions are unmasked and FSW which indeed has the invalid operation flag set. From randomly sampling registers at run and build time, the exceptions are usually masked (FCW=0x137f).

The Intel software developer's manual specifically mentions this case and suggests clearing pending exceptions through fclex/fnclex to avoid raising such exceptions. I'm not yet certain of the implications this has. As far as I've understood the SDM, in 64 bit mode this will always directly raise an math fault (#MF) while in 32 bit protected mode the fault will only be raised on the next floating point instruction. That would explain why this only affects x86_64.

[korli]

FPC SVN trunk: ​https://svn.freepascal.org/svn/fpc/trunk

[korli]

I tried to build with ​https://github.com/graemeg/freepascal/commit/485bdb642b1d73eac36ee2618036ddd2a65939ea on a current nightly on KVM (the bootstrap compiler seems too old for the trunk). The builds ends with success. Probably solved by hrev55135