[9fans] signal.h in APE for newbies

[9fans] signal.h in APE for newbies

[Fernan Bolando]

Hi

Can anybody point me to a document discussing the signal handling in APE.

One of the program I am porting is using signal to intercept SIGFPE.
It works under linux, but after I ported it to plan9 it is no longer
working.
I was able to intercept SIGINT.

When I trigger a division by zero the handler is not called, I just
get trap 19 message.

fernan
--
http://www.fernski.com

Re: [9fans] signal.h in APE for newbies

[Charles Forsyth]

> When I trigger a division by zero the handler is not called, I just
> get trap 19 message.

if i do a floating-point division by zero, the SIGFPE signal handler is called,
because ape's signal recognises the initial "sys: fp: ".  (ie, it works for me.)

it doesn't work for an integer division by zero, which produces a different message for the underlying notify:

8.out 205840: suicide: sys: trap: divide error pc=0x00001089

but that's fine too! Linux's signal(2) says, apparently referring to POSIX rules:

        ....  Integer division by zero  has  undefined  result.
       On some architectures it will generate a SIGFPE signal.  (Also dividing
       the most negative integer by -1 may generate  SIGFPE.)   Ignoring  this
       signal might lead to an endless loop.

Linux might not be particularly good at documenting this particular area,
so perhaps the standard(s) have useful hints or advice that APE could follow.

Re: [9fans] signal.h in APE for newbies

[Fernan Bolando]

On 7/4/08, Charles Forsyth <forsyth@terzarima.net> wrote:
> > When I trigger a division by zero the handler is not called, I just
>  > get trap 19 message.
>
>
> if i do a floating-point division by zero, the SIGFPE signal handler is called,
>  because ape's signal recognises the initial "sys: fp: ".  (ie, it works for me.)
>
>  it doesn't work for an integer division by zero, which produces a different message for the underlying notify:
>
>  8.out 205840: suicide: sys: trap: divide error pc=0x00001089
>
>  but that's fine too! Linux's signal(2) says, apparently referring to POSIX rules:
>
>         ....  Integer division by zero  has  undefined  result.
>        On some architectures it will generate a SIGFPE signal.  (Also dividing
>        the most negative integer by -1 may generate  SIGFPE.)   Ignoring  this
>        signal might lead to an endless loop.
>
>  Linux might not be particularly good at documenting this particular area,
>  so perhaps the standard(s) have useful hints or advice that APE could follow.
>
>

Any chance this is some 9vx issue? I tried the test code below it
worked in 9grid.jp ,but gave the following message in 9vx

8.out 89: suicide: sys: trap: 19 (reserved) pc=0x00001067


#include <stdio.h>
#include <signal.h>

void e_hand(int sig)
{
	printf("Signal");
	return;
}
int main()
{
double a, d;

                  d = 5.0;

	signal(SIGFPE, e_hand);
	a = 1/(d-5);
	return 0;
}


--
http://www.fernski.com

Re: [9fans] signal.h in APE for newbies

[Russ Cox]

> Any chance this is some 9vx issue? I tried the test code below it
> worked in 9grid.jp ,but gave the following message in 9vx

You are caught in quite a tangled web.

The hardware gets a floating point trap,
Linux/BSD/OS X turns it into a SIGFPE,
vx32 turns it back into a hardware trap,
Plan 9 turns it into a note,
APE turns it back into a SIGFPE.

Unfortunately for you, vx32 does not do
a very good job turning SIGFPEs into the
correct hardware trap.  Someone needs to
go through the various systems and figure
out what the right mapping is from
info->si_code back to x86 exception code.
When I started to do this, I got very confused
and didn't care enough to muddle through.

Russ

Re: [9fans] signal.h in APE for newbies

[Charles Forsyth]

> Any chance this [fp signals in APE] is some 9vx issue?

vx32 converts SIGFPE to the SIMD SSE/SSE2 trap 19, but
9vx expects only x87.

i had wondered the other day whether there were AMD/Intel processors
in common use that supported x87 but not SSE/SSE2.  should 8c start
using SSE as the plan 9 amd64 compiler does? could it support that exclusively?

Re: [9fans] signal.h in APE for newbies

[erik quanstrom]

> vx32 converts SIGFPE to the SIMD SSE/SSE2 trap 19, but
> 9vx expects only x87.
>
> i had wondered the other day whether there were AMD/Intel processors
> in common use that supported x87 but not SSE/SSE2.  should 8c start
> using SSE as the plan 9 amd64 compiler does? could it support that exclusively?

it probablly could.  but i worry about low-power x86
devices.  perhaps floating point is just not an issue
on them?

i would be happy to just use the amd64 compiler and let
64 bit support be the bright line.

if that's not an option, perhaps it is best to fork the
32-bit compiler.  perhaps renaming the current x86 +
x87 compiler ⅛c and use only sse2 with 8c.

- erik

Re: [9fans] signal.h in APE for newbies

[Charles Forsyth]

> it probablly could.  but i worry about low-power x86
> devices.  perhaps floating point is just not an issue
> on them?

do they support fp at all, or just x87 not sse?
i can't remember what is on the little soekris boards

Re: [9fans] signal.h in APE for newbies

[erik quanstrom]

>> it probablly could.  but i worry about low-power x86
>> devices.  perhaps floating point is just not an issue
>> on them?
>
> do they support fp at all, or just x87 not sse?
> i can't remember what is on the little soekris boards

according to wikipedia, geode before the nx don't support sse,
but the do support fp.  i belive that the common soekris
have pre-nx chips, as the slowest nx chip is 667mhz.

- erik

Re: [9fans] signal.h in APE for newbies

[Russ Cox]

> vx32 converts SIGFPE to the SIMD SSE/SSE2 trap 19, but
> 9vx expects only x87.

Ah.  So that explains where the 19 came from.
I had wondered how I got that wrong.  ;-)
Vx32 originally disallowed the x87 so that the
VM execution would be more deterministic,
but it was easier to turn on x87 support than
change 8c.

> i had wondered the other day whether there were AMD/Intel processors
> in common use that supported x87 but not SSE/SSE2.  should 8c start
> using SSE as the plan 9 amd64 compiler does? could it support that exclusively?

I have pushed hard to keep post-386 dependencies
from creeping into the system.  That's why, for example,
libthread uses locked INCL and DECL instructions
instead of the commented-out XADDL implementation
that would only work on the 486 and later.
I harbor no illusion that we've succeeded entirely, but
I do hope that if someone dug up a 386, it would not be
too much work to get it to boot and run.

Just the other day Sape and I were discussing whether
some code he was working on should add a dependency
on CMPXCHG8B (64-bit compare and swap), which was
only introduced in the Pentium.  I think we decided there
is a way to avoid it in favor of the 386-supported 32-bit XCHG.

The SSE instructions were only added in the Pentium III;
SSE2 only came in with the Pentium 4.

I realize that, at this point, keeping 386 support is bordering
on retrocomputing, but it's hard to know where to draw the line.
I would be inclined to leave the 386 support as it is
and assume that people who want to take advantage of
new features will switch to the x86-64 once the port is available.
But I might just be out of touch.

Russ