[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 1/2] linux-user/s390x: signal with SIGFPE on compare-and-t
From: |
jonathan.albrecht |
Subject: |
Re: [PATCH v2 1/2] linux-user/s390x: signal with SIGFPE on compare-and-trap |
Date: |
Fri, 09 Jul 2021 10:23:12 -0400 |
User-agent: |
Roundcube Webmail/1.1.12 |
On 2021-07-08 1:08 pm, Richard Henderson wrote:
On 7/7/21 6:42 AM, Jonathan Albrecht wrote:
+ sig = TARGET_SIGFPE;
+ if ((n & 0x03) == 0) {
+ /* An IEEE exception, simulated or otherwise. */
if (n & 0x80) {
n = TARGET_FPE_FLTINV;
} else if (n & 0x40) {
@@ -121,13 +123,12 @@ void cpu_loop(CPUS390XState *env)
n = TARGET_FPE_FLTUND;
} else if (n & 0x08) {
n = TARGET_FPE_FLTRES;
- } else {
- /* ??? Quantum exception; BFP, DFP error. */
- goto do_sigill_opn;
}
- sig = TARGET_SIGFPE;
- goto do_signal_pc;
+ } else {
+ /* compare-and-trap */
+ n = 0;
}
Thanks for the review. I should have a v3 ready shortly.
Nearly, but not quite. Replace the ??? Quantum exception with n = 0,
otherwise si_code will be garbage for that case.
Thx I'll fix that.
The structure of the kernel code is
if (n != 0) {
/* do_fp_trap */
si_code = 0;
if ((n & 3) == 0) {
/* select on bits 6 & 7 */
}
raise sigfpe w/ si_code
} else {
raise sigill
}
The comment for compare-and-trap is misleading, because there are lots
of entries in "Figure 6-2. Data-exception codes (DXC)" which arrive
there and are not compare-and-trap.
I'll make the comment less specific.
As a general comment, I think a single switch over DXC would be
cleaner for both kernel and qemu. It seems like giving different
si_code for e.g. "0x40 IEEE division by zero" and "0x43 Simulated IEEE
division by zero" is actively incorrect.
I went over the DXC section and I see what you mean about the si_codes
for simulated IEEE exceptions. I'll plan on handling those the same as
non-simulated IEEE if no objections. Otherwise all non-IEEE will have
si_code == 0 except DXC == 0x00 will still goto do_sigill_opn.
r~