qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] alpha qemu arithmetic exceptions


From: Al Viro
Subject: Re: [Qemu-devel] [RFC] alpha qemu arithmetic exceptions
Date: Tue, 8 Jul 2014 08:13:34 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

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?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]