From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 106792 invoked by alias); 30 Jun 2016 12:58:44 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 106770 invoked by uid 89); 30 Jun 2016 12:58:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: smtp.gentoo.org Received: from smtp.gentoo.org (HELO smtp.gentoo.org) (140.211.166.183) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 30 Jun 2016 12:58:42 +0000 Received: from vapier.lan (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with SMTP id 50D4A340E7C; Thu, 30 Jun 2016 12:58:40 +0000 (UTC) Date: Thu, 30 Jun 2016 12:58:00 -0000 From: Mike Frysinger To: Yao Qi Cc: "gdb-patches@sourceware.org" Subject: Re: [PATCH] Set unknown_syscall differently on arm linux Message-ID: <20160630125840.GB4685@vapier.lan> Mail-Followup-To: Yao Qi , "gdb-patches@sourceware.org" References: <1467105996-18063-1-git-send-email-yao.qi@linaro.org> <20160629174103.GW4685@vapier.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JMCz+drDJ1SjddZX" Content-Disposition: inline In-Reply-To: X-IsSubscribed: yes X-SW-Source: 2016-06/txt/msg00535.txt.bz2 --JMCz+drDJ1SjddZX Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 1026 On 30 Jun 2016 08:52, Yao Qi wrote: > On Wed, Jun 29, 2016 at 6:41 PM, Mike Frysinger wrote: > > On 28 Jun 2016 10:26, Yao Qi wrote: > >> Currently, we use 123456789 as unknown or illegal syscall number, and > >> expect program return ENOSYS. Although 123456789 is an illegal syscall > >> number on arm linux, kernel sends SIGILL rather than returns -ENOSYS. > > > > err, what ? calling random syscalls should not result in signals being > > generated (ignoring obvious ones like __NR_kill). is the kernel broken= ? > > i think this needs more investigation & explanation. >=20 > I checked kernel source arch/arm/kernel/traps.c:arm_syscall, and that is = how > I get the knowledge that kernel doesn't raise SIGIILL if sysno is within > 0xf0001..0xf07ff. That is intentional, but I don't know why arm kernel b= ehaves > this way. wow, that code is messed up. can you raise a bug with them ? there's even more code paths in there that result in SIGSEGV too. the history predates 2.4.0 afaict. -mike --JMCz+drDJ1SjddZX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXdReAAAoJEEFjO5/oN/WBwrsQAJxLk373n+Z8Ls6nVYDhyb1V OET7qNBNyThlAJBCZGNtNcMfPP4lNJgw33kN71q/fu00rzrLFIgbv51wVs65xX1h uYLlokAtBWJ8MO4AYZf9qpGSvsxc5ZSZXK47XMGwKWBvNaaMRbXl6ND3xDxPazO2 Ako2s2IgejLPvBrouD8E5O9w8XZXzhMW1rhWNXlGYZV/DCtWoPpUN8VVVfV+z9pe lhmTk1+XWMxed3uAOUQU6zhyOr6G6OiA4oiU7sECr5JQ4LCtJVa1wO2gK0Yz/X7K 6HpBHhWgKuRUO1XerbOO8vXy7cvgtY60tvqwPFFslGWIKwVqlXyU6MStH7zwll8g 9eQpTq9l4CYS5zF1/4bJgUhdJWjB0qSBZQRJuJu2N0dAr2Ot3IS/XKTbkGK5vssB qo7VYvONqppO8+Vt3n1qrpSmtMZ+UleMZeFNXgMOZM6Q3winu8esKqq022ovJPev Bu5ijFQR5iyJ2jeXqgPRlyRv4+gsWdBw3MKlv/8iMWBJCPyRF4u1+6Iskb91fE5g MoRNShTTBwmYbHRI0pWt8HmYVsySa2KyXvD8KzVixb6EdS4LYqMdTYDZAe8QpJRo BhhCiWr+ITzhuc8V+K44aPR3p/qrYD9LAJn6+QM8duDiFmbQIISTUTbjzwvXopTh aktkF5fnZvbx9cEoBOk2 =CLEJ -----END PGP SIGNATURE----- --JMCz+drDJ1SjddZX--