Re: Libm core dump with SIGILL

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> Isn't EMODD an optional instruction?  I wonder if the issue is that it's not$

Yes.  "The EMODx instructions are in the emulated-only group [...]",
which means that processors not implementing it will take an
instruction-emulation exception for it.

I don't recall whether anyone said what NetBSD version this was being
done under.  But in 4.0.1 and 5.2, looking at intvec.S, I find

#ifndef NO_INSN_EMULATE
/*
 * Table of emulated Microvax instructions supported by emulate.s.
 * Use noemulate to convert unimplemented ones to reserved instruction faults.
 */

EMODD is opcode 0x74.  This does not appear in the following table, and
the code the relevant SCB vector points to sends it to noemulate, which
tries to execute opcode 0xffff, which is "reserved for all time" as a
way to be sure of producing a reserved-instruction fault.

Now, that does say "Microvax", and the the MicroVAX-I and MicroVAX-II
each include EMODD, so there's _some_ justification, even if only
historical, for this.  But, assuming this code is still set up the same
way on whatever version was in use, EMODD will not be emulated on
processors that don't provide it.  And the VAX infnan() uses EMODD with
a third operand of $0x8000 and a comment "# generates the reserved
operand fault", which looks to me as though someone should have used a
simpler instruction, like TSTF, that's in the core instruction set
rather than the emulated-only group.  (Since the emulation stuff was
apparently written for processors that did implement EMODD, I guess
that should be phrased as "someone should have updated it to use".)

But that turns out to be probably not relevant.  IIRC this was said to
be done under simh.  A quick look at the simh version I have at ready
hand makes me think it does provide EMODD, and should take a reserved
operand fault on that instruction.  This in turn means that Ragge's
quote, showing that reserved operand fault from user mode turns into
SIGILL, is spot on the mark after all.

As for the original issue, it looks to me as though it is either pilot
error (if the package is documented as requiring IEEE floats), a bug in
the documentation (if it's supposed to require IEEE floats but isn't
documented that way), or a bug in the tests (if it's not supposed to
require IEEE floats).

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B