OK, I think the problem is the handling of dc->fsr_qne in
trans_STDFQ, lines 4583 and 4593 -- the code is evaluating
dc->fsr_qne at translation time and not at runtime.
Hi Richard,
I applied the 6 patches and then ran a divide-by-zero test on the Solaris image. The result was a crash
(qemu) qemu: fatal: Trap 0x08 (FPU Exception) while interrupts disabled, Error state
pc: f0066d80 npc: f0066d84
%g0-7: 00000000 01086002 00000000 00002000 00000000 fc067b80 00000001 f638b180
%o0-7: f025ef5c 00000000 00000000 f6376648 00000000 00000000 fc067b80 f004149c
%l0-7: 04401087 00010a10 00010a14 fc067b80 fc067f70 00000080 00000001 fc067b80
%i0-7: 00000000 01080000 00080000 00000002 0f800000 ef718cb0 effff510 000109ec
%f00: ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff
%f08: 0000000040400000 ffffffffffffffff ffffffffffffffff ffffffffffffffff
%f16: ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff
%f24: ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff
psr: 04001087 (icc: ---- SPE: S--) wim: 00000002
fsr: 01090000 y: 00000000
I've seen that PC address before -- I'm pretty sure it is the STDFQ instruction in the kernel trap handler, and if I'm reading the fsr correctly that is confirmed by the fact that it is sequence-error type FPE which only occurs for STDFQ. Without a bit of further poking around with the debugger I don't know what's happening beyond that. I will keep looking but thought I'd provide immediate results in case this rings a bell for you.
If it would be helpful, I could share a disk image with Solaris, gnu tools, the test examples, etc. It's under 500MB compressed and I think I have enough google drive space to accommodate that at the moment.
-- Carl
On 8/16/24 00:23, Richard Henderson wrote:
Hi Carl, While digging through the manual to figure out if we were really doing the right thing raising the fp exception, I found the fpu exception state machine. I'm not sure it's worth emulating the fp_exception_pending state, but it's certainly easy enough to emulate the fp_executing/fp_exception states.In addition, this simplifies the implementation of STDFQ, restricts FQ to sparc32 system mode, and handles migration. Would you please double-check this against your Solaris images? r~ Carl Hauser (2): target/sparc: Add FQ and FSR.QNE target/sparc: Populate sparc32 FQ when raising fp exception Richard Henderson (4): target/sparc: Restrict STQF to sparcv9 target/sparc: Add FSR_QNE to tb_flags target/sparc: Implement STDFQ target/sparc: Add gen_trap_if_nofpu_fpexception target/sparc/cpu.h | 30 ++++++++- target/sparc/fop_helper.c | 4 ++ target/sparc/int32_helper.c | 32 ++++----- target/sparc/machine.c | 25 +++++++ target/sparc/translate.c | 126 ++++++++++++++++++++++++++---------- target/sparc/insns.decode | 4 +- 6 files changed, 169 insertions(+), 52 deletions(-)
