From: Andrey Savchenko <bircoph@altlinux.org>
To: Bruno Haible <bruno@clisp.org>
Cc: Ivan Zakharyaschev <imz@altlinux.org>, bug-gnulib@gnu.org
Subject: Re: [RFC PATCH] test-c-stack2.sh: skip if the platform sent SIGILL on an invalid address.
Date: Sat, 29 Dec 2018 14:31:11 +0300 [thread overview]
Message-ID: <20181229143111.6c78b9849a8a681a47a420a0@altlinux.org> (raw)
In-Reply-To: <1553285.vUXQ5OdejE@omega>
[-- Attachment #1: Type: text/plain, Size: 1521 bytes --]
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 #2: Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2018-12-29 13:43 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-15 12:50 [RFC PATCH] test-c-stack2.sh: skip if the platform sent SIGILL on an invalid address Ivan Zakharyaschev
2018-12-20 2:24 ` Bruno Haible
2018-12-28 14:23 ` Ivan Zakharyaschev
2018-12-29 11:17 ` Bruno Haible
2018-12-29 11:31 ` Andrey Savchenko [this message]
2018-12-29 14:03 ` Bruno Haible
2018-12-29 14:31 ` Dmitry V. Levin
2018-12-29 14:54 ` Bruno Haible
2018-12-29 15:03 ` Ivan Zakharyaschev
2018-12-29 16:30 ` Dmitry V. Levin
2018-12-29 20:13 ` Ivan Zakharyaschev
2018-12-30 4:49 ` Bruno Haible
2018-12-29 13:54 ` Dmitry V. Levin
2018-12-29 15:15 ` Ivan Zakharyaschev
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
List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181229143111.6c78b9849a8a681a47a420a0@altlinux.org \
--to=bircoph@altlinux.org \
--cc=bruno@clisp.org \
--cc=bug-gnulib@gnu.org \
--cc=imz@altlinux.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).