From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28110 invoked by alias); 4 Sep 2019 20:56:48 -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 28100 invoked by uid 89); 4 Sep 2019 20:56:47 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 04 Sep 2019 20:56:46 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0A07D30084AC; Wed, 4 Sep 2019 20:56:45 +0000 (UTC) Received: from localhost (unused-10-15-17-196.yyz.redhat.com [10.15.17.196]) by smtp.corp.redhat.com (Postfix) with ESMTP id BAA8E5C207; Wed, 4 Sep 2019 20:56:44 +0000 (UTC) From: Sergio Durigan Junior To: Pedro Alves Cc: GDB Patches , Eli Zaretskii , Ruslan Kabatsayev Subject: Re: [PATCH v2] Improve ptrace-error detection on Linux targets References: <20190819032918.3536-1-sergiodj@redhat.com> <20190826183205.19008-1-sergiodj@redhat.com> <28c4f743-91f1-59c3-83ff-3f791811f996@redhat.com> <87mufrai1z.fsf@redhat.com> <87zhjjrh7n.fsf@redhat.com> <87d0gfrewj.fsf@redhat.com> <587b2e6b-15ec-0ba1-f425-82ec45eb4ca7@redhat.com> Date: Wed, 04 Sep 2019 20:56:00 -0000 In-Reply-To: <587b2e6b-15ec-0ba1-f425-82ec45eb4ca7@redhat.com> (Pedro Alves's message of "Wed, 4 Sep 2019 21:35:19 +0100") Message-ID: <875zm7rd9v.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2019-09/txt/msg00043.txt.bz2 On Wednesday, September 04 2019, Pedro Alves wrote: > On 9/4/19 9:21 PM, Sergio Durigan Junior wrote: >>> or extended-remote + "(gdb) attach" ? >> I'm trying to come up with a way to test this. The only way would be to >> make gdbserver successfully start so that we could perform an >> extended-remote connection from GDB. However, if gdbserver starts >> without problems, this means that the ptrace check succeeded and that >> there are no ptrace restrictions in place. Therefore, an "attach" would >> succeed as well. Which means that even if we're running GDB in a >> ptrace-restricted system, things will go OK as long as gdbserver is not >> restricted. In this case, we wouldn't see any error messages IIUC. > > So > > $ gdbserver --multi :9999 > > exits with error immediately? Yeah. > You could start gdbserver with the restrictions off (like a long > lived daemon), and then while gdbserver is running enable > restrictions, I suppose. Ah, right, I think that would also work. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/