From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:51397)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <viro@ftp.linux.org.uk>) id 1X4Par-0003Yy-1h
	for qemu-devel@nongnu.org; Tue, 08 Jul 2014 03:13:38 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <viro@ftp.linux.org.uk>) id 1X4Paq-0006Jf-5Z
	for qemu-devel@nongnu.org; Tue, 08 Jul 2014 03:13:36 -0400
Received: from zeniv.linux.org.uk ([2002:c35c:fd02::1]:48886)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <viro@ftp.linux.org.uk>) id 1X4Pap-0006JV-UV
	for qemu-devel@nongnu.org; Tue, 08 Jul 2014 03:13:36 -0400
Date: Tue, 8 Jul 2014 08:13:34 +0100
From: Al Viro <viro@ZenIV.linux.org.uk>
Message-ID: <20140708071334.GA21956@ZenIV.linux.org.uk>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140708065436.GB18016@ZenIV.linux.org.uk>
Sender: Al Viro <viro@ftp.linux.org.uk>
Subject: Re: [Qemu-devel] [RFC] alpha qemu arithmetic exceptions
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Richard Henderson <rth@twiddle.net>
Cc: Peter Maydell <peter.maydell@linaro.org>, QEMU Developers <qemu-devel@nongnu.org>

On Tue, Jul 08, 2014 at 07:54:36AM +0100, Al Viro wrote:
> On Mon, Jul 07, 2014 at 11:03:08PM -0700, Richard Henderson wrote:
> > On 07/07/2014 09:20 PM, Al Viro wrote:
> > > and I'm reasonably sure that this is what they did internally.  You are
> > > proposing to do 4 cases in all their messy glory in qemu itself...
> > 
> > Yes.  Primarily because we *have* to do so for the linux-user case.
> > 
> > > And that's not even going into generating the right si_code for that SIGFPE.
> > > What produces those TARGET_GEN_FLTINE and friends?
> > 
> > linux-user/main.c, cpu_loop.
> 
> That's where we consume it; where is it produced?  Sure, explicit
> gentrap in alpha code will lead there, with whatever we have in
> $16 deciding what'll go into si_code, but where does that happen on
> fp exception codepaths?  IOW, what sets si_code on those?

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?