From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:32823) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X4Wma-000826-VD for qemu-devel@nongnu.org; Tue, 08 Jul 2014 10:54:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X4WmU-0003X3-Dq for qemu-devel@nongnu.org; Tue, 08 Jul 2014 10:54:12 -0400 Received: from mail-qg0-x232.google.com ([2607:f8b0:400d:c04::232]:46128) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X4WmU-0003Wn-8h for qemu-devel@nongnu.org; Tue, 08 Jul 2014 10:54:06 -0400 Received: by mail-qg0-f50.google.com with SMTP id j5so5041200qga.37 for ; Tue, 08 Jul 2014 07:54:05 -0700 (PDT) Sender: Richard Henderson Message-ID: <53BC0607.2070501@twiddle.net> Date: Tue, 08 Jul 2014 07:53:59 -0700 From: Richard Henderson MIME-Version: 1.0 References: <20140704072937.GU18016@ZenIV.linux.org.uk> <20140705014055.GV18016@ZenIV.linux.org.uk> <20140705210951.GX18016@ZenIV.linux.org.uk> <20140705225513.GY18016@ZenIV.linux.org.uk> <53BAAAAE.2060009@twiddle.net> <20140707150629.GZ18016@ZenIV.linux.org.uk> <53BAC8CC.9070301@twiddle.net> <20140708042037.GA18016@ZenIV.linux.org.uk> <53BB899C.30901@twiddle.net> <20140708065436.GB18016@ZenIV.linux.org.uk> <20140708071334.GA21956@ZenIV.linux.org.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] alpha qemu arithmetic exceptions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell , Al Viro Cc: QEMU Developers On 07/08/2014 01:05 AM, Peter Maydell wrote: > On 8 July 2014 08:13, Al Viro wrote: >> Actually, that's badly worded; what codepath ends up setting si_code on >> e.g. fp addition overflows? In system mode it's done by completion code >> in the kernel, but AFAICS in user mode there are only two places where it >> might happen - one is gentrap handling and another - osf_setsysinfo(2) >> emulation for TARGET_SSI_IEEE_FP_CONTROL. What I don't understand is how >> do we get from float_raise(&FP_STATUS, float_flag_overflow) in fpu/softfloat.c >> to either of those. >> >> IOW, suppose I do >> x = DBL_MAX; >> feenableexcept(FE_ALL_EXCEPT); >> x *= x; >> I understand how I'll get SIGFPE, but what will set correct si_code in >> siginfo I'll see in the hanler? > > The code we have currently may well be buggy, but the correct > place to set si_code is (as Richard says) the Alpha cpu_loop() in > linux-user/main.c, which has access to the trap type that just > caused us to stop executing code, plus the CPUState, which > should be enough information to set si_code correctly. In > particular the GENTRAP case seems to be setting a variety > of different si_code values for SIGFPE. The gentrap case is a red-herring. The case you're looking for is EXC_ARITH. The path is from arith_excp dynamic_excp cpu_loop_exit longjmp cpu_exec cpu_loop It's also true that we don't install the correct si_code there, but we could. Mostly the gcc/glibc test cases really only care that SIGFPE gets raised, not what the codes are, so I haven't bothered. r~