All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kevin D. Kissell" <kevink@paralogos.com>
To: Shane McDonald <mcdonald.shane@gmail.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Unexpected behaviour when catching SIGFPE on FPU-less system
Date: Tue, 04 May 2010 11:55:59 -0700	[thread overview]
Message-ID: <4BE06DBF.3070409@paralogos.com> (raw)
In-Reply-To: <4BE0479E.6060506@paralogos.com>

Kevin D. Kissell wrote:
> Shane McDonald wrote:
>   
>> In the following chunk of code from cp1emu.c:
>>   
>>     
> [snip]
>   
>> value gets set to an initial value of 0x400, and ctx->fcr31
>> comes in with an initial value of 0x8420.
>> By the time we hit the if statement around the return SIGFPE, ctx->fcr31
>> has been set to 0x8400, not the 0x400 I implied.
>>   
>>     
> Ah, well that would rather change things, and you *would* get an
> exception there.  As written, the code doesn't seem to allow the pending
> exception (.._X) bits to be cleared by the CTC.
>   
>> Nevertheless, that's not the problem.  
>>     
> Maybe it is.  I don't have my MIPS specs handy anymore, but just what is
> supposed to clear a pending exception bit in a real FPU?
>   
 From old-ish MIPS32 specs out there on the web, it looks like the 
emulator was doing the right thing in raising the exception - it's 
specifically called out in the CTC1 definition that writing a value with 
both a Cause and an Enable (_X and _E) bit set will throw an exception.  
The question is:  Why wasn't the Cause bit cleared?  As I mentioned last 
night, in current kernels running on a real FPU, it gets cleared as part 
of the assembly-language preamble to servicing a FPU exception, a path 
which is definitely not taken in the emulator case, which is driven by 
coprocessor unusable exceptions.   So now I'm actually confused by two 
things:  One is where the emulator *should* have its _X flags cleared, 
and the other is how the current kernel/signal code communicates the 
nature of a floating point exception to the user.  I had thought that 
either we had a model where a SIGFPE signal carried the FPCR bits as 
part of its payload (something I've done for other architectures and 
could have sworn I'd done for MIPS at one point or another), or that the 
signal handler can inspect the FPCR to know what kind of exception it 
was.  As near as I can tell, when there's a real FPU, we wipe out the 
evidence before we save the context.

          Regards,

          Kevin K.

  parent reply	other threads:[~2010-05-04 18:56 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-03  2:17 Unexpected behaviour when catching SIGFPE on FPU-less system Shane McDonald
2010-05-03 20:39 ` Kevin D. Kissell
2010-05-03 20:47 ` Kevin D. Kissell
     [not found]   ` <k2hb2b2f2321005031843l87f39f36h960153cae3ec5020@mail.gmail.com>
2010-05-04  2:04     ` Kevin D. Kissell
     [not found]       ` <n2pb2b2f2321005032049h56cd72ceh3ac7120c547b59c5@mail.gmail.com>
2010-05-04  4:35         ` Shane McDonald
2010-05-04  6:56           ` Shane McDonald
2010-05-04  7:13             ` Shane McDonald
2010-05-04 11:16             ` Kevin D. Kissell
2010-05-04 12:56               ` Shane McDonald
2010-05-04 16:13                 ` Kevin D. Kissell
2010-05-04 18:44                   ` Ralf Baechle
2010-05-04 18:58                     ` Kevin D. Kissell
2010-05-04 19:28                     ` Geert Uytterhoeven
2010-05-04 19:30                       ` Manuel Lauss
2010-05-04 19:44                         ` Geert Uytterhoeven
2010-05-04 20:01                         ` David Daney
2010-05-04 21:23                           ` Kevin D. Kissell
2010-05-04 18:55                   ` Kevin D. Kissell [this message]
2010-05-04 21:52                   ` Kevin D. Kissell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BE06DBF.3070409@paralogos.com \
    --to=kevink@paralogos.com \
    --cc=linux-mips@linux-mips.org \
    --cc=mcdonald.shane@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.