From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 208.118.235.0/24 X-Spam-Status: No, score=-3.6 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 4280C1F405 for ; Sat, 29 Dec 2018 14:47:13 +0000 (UTC) Received: from localhost ([127.0.0.1]:38666 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gdFtP-0004qV-IB for normalperson@yhbt.net; Sat, 29 Dec 2018 09:47:11 -0500 Received: from eggs.gnu.org ([208.118.235.92]:47948) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gdFtF-0004pz-KO for bug-gnulib@gnu.org; Sat, 29 Dec 2018 09:47:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gdFeQ-0003us-EC for bug-gnulib@gnu.org; Sat, 29 Dec 2018 09:31:46 -0500 Received: from vmicros1.altlinux.org ([194.107.17.57]:49422) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gdFeQ-0003sq-1k for bug-gnulib@gnu.org; Sat, 29 Dec 2018 09:31:42 -0500 Received: from mua.local.altlinux.org (mua.local.altlinux.org [192.168.1.14]) by vmicros1.altlinux.org (Postfix) with ESMTP id E13A072CC6C; Sat, 29 Dec 2018 17:31:40 +0300 (MSK) Received: by mua.local.altlinux.org (Postfix, from userid 508) id CDF5E9657E0; Sat, 29 Dec 2018 17:31:40 +0300 (MSK) Date: Sat, 29 Dec 2018 17:31:40 +0300 From: "Dmitry V. Levin" To: Andrey Savchenko Subject: Re: [RFC PATCH] test-c-stack2.sh: skip if the platform sent SIGILL on an invalid address. Message-ID: <20181229143140.GA21975@altlinux.org> References: <20181215125047.2071-1-imz@altlinux.org> <1787335.ZHZPG2Za76@omega> <1553285.vUXQ5OdejE@omega> <20181229143111.6c78b9849a8a681a47a420a0@altlinux.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jRHKVT23PllUwdXP" Content-Disposition: inline In-Reply-To: <20181229143111.6c78b9849a8a681a47a420a0@altlinux.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (no timestamps) [generic] [fuzzy] X-Received-From: 194.107.17.57 X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Ivan Zakharyaschev , bug-gnulib@gnu.org, Bruno Haible Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 29, 2018 at 02:31:11PM +0300, Andrey Savchenko wrote: > On Sat, 29 Dec 2018 12:17:32 +0100 Bruno Haible wrote: > > > As for the SIGILL peculiarity, it has a reason in the Elbrus architec= ture.=20 > > > ... > > > And it's not a segmentation fault. > >=20 > > I believe you should make it signal a SIGSEGV or SIGBUS, not SIGILL, for > > the following reasons: > >=20 > > * Look at the second table in > > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.htm= l. > > It defines a couple of signal codes for SIGILL, SIGSEGV, and SIGBUS. > > It implies that SIGILL means an invalid instruction (and "illegal ope= rand" > > means an invalid operand that is in the instruction stream). > > Whereas SIGSEGV and SIGBUS mean a problem with an instruction in comb= ination > > with a memory address. > >=20 > > * The main users of SIGSEGV and SIGBUS are catching stack overflow, gar= bage > > 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 th= e lines, > > until you fix that port, to produce SIGSEGV or SIGBUS instead of SIGI= LL. >=20 > 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. It's all up to the kernel what signal to generate in response to that particular non-SIGSEGV kind of trap. I agree with Bruno here, as long as the code in question causes SIGILL, the architecture is not compatible and its users will suffer more because of this unneeded incompatibility. --=20 ldv --jRHKVT23PllUwdXP Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJcJ4VMAAoJEAVFT+BVnCUIwtEQAPO18TEaAeKfvE6jGZWzAuFc C8TY0JdAu6tRA1zH8nnKqCLlhIN/pj0cyt0pH6Gf8UYZbzjcqC641HQ4WELxp9EO 1va5+6Lkm9Ntv4nU7uMBFBFugn8YZ7/ZokXHArCM7QHR3s76k5C/qz/dbkSK/x5o 3aBfeulLJSwKzcVCP3YXMY+MFpxNSIF6RqNhmX655o6w7XJ4KdLrqMrRAPMXtTxH axcB4rn4ERBJ8Cdpq+oEB3seQr+Tl/yvkXQf+Ts+y0aYMZ7f12Bi7B6lh2zDcZKa zitOTy3vtZddagwKLpN9c/oscEA/xTjGOPgdZ29RocK0IIAFN9qIJSmjhHgbLi8J mwlx6tkqnUJNOT8rZlqBKeyQ6VTQsuCyB+bLayC8C3gUOCdjqwDeVDyoG4hm08On WrLXiPf7f+tA3msQ/FtGiaZG5GGxKJhM8tYh3nRf/pxGKCT271HE6N3pGv6BH1qB 051mLR08wt47Xp2No/3YFxVUUXJbYyaOlXzIoa2fjCIXS6FL57pTY/jqUFNUr3hn bR5res/YseZyC4A+7xgeEQqWs0Xj+4PtRqJt/SAWxTL4kr944WHkdt5zED1KqERJ Kk40scca+8v2zKUZRFuyDvLe9Usml9225AJgYDAAvz9omsWJZEbnyYQre5UPs0IS JOsl5fQMuGCgSszUyyuK =HDEM -----END PGP SIGNATURE----- --jRHKVT23PllUwdXP--