Hi all!

On Sat, 29 Dec 2018 12:17:32 +0100 Bruno Haible wrote:
> > As for the SIGILL peculiarity, it has a reason in the Elbrus architecture. 
> > ...
> > And it's not a segmentation fault.
> I believe you should make it signal a SIGSEGV or SIGBUS, not SIGILL, for
> the following reasons:
> * Look at the second table in
>   http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html.
>   It defines a couple of signal codes for SIGILL, SIGSEGV, and SIGBUS.
>   It implies that SIGILL means an invalid instruction (and "illegal operand"
>   means an invalid operand that is in the instruction stream).
>   Whereas SIGSEGV and SIGBUS mean a problem with an instruction in combination
>   with a memory address.
> * The main users of SIGSEGV and SIGBUS are catching stack overflow, garbage
>   collection, and similar (e.g. by use of GNU libsigsegv). The fact that
>   you observe an incompatibility between your Linux adaptation and
>   application programs that work fine across Linux/BSD/AIX/Solaris is a sure
>   indication that you will encounter similar incompatibilities along the 
> lines,
>   until you fix that port, to produce SIGSEGV or SIGBUS instead of SIGILL.

This is not possible. Four generations of hardware are already
manufactured and they use SIGILL for such cases. It may be fixed in
future generations if CPU designers will agree to do so, but we
have to deal with already produced and used in production hardware.

Best regards,
Andrew Savchenko

Attachment: pgpraseYmZo15.pgp
Description: PGP signature

Reply via email to