From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128126 invoked by alias); 4 Sep 2019 20:35:25 -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 128100 invoked by uid 89); 4 Sep 2019 20:35:24 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=lived 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:35:23 +0000 Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BB0537BDA9 for ; Wed, 4 Sep 2019 20:35:21 +0000 (UTC) Received: by mail-wr1-f69.google.com with SMTP id v15so12502385wrg.13 for ; Wed, 04 Sep 2019 13:35:21 -0700 (PDT) Received: from ?IPv6:2001:8a0:f913:f700:56ee:75ff:fe8d:232b? ([2001:8a0:f913:f700:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id u8sm132988wmj.3.2019.09.04.13.35.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Sep 2019 13:35:19 -0700 (PDT) Subject: Re: [PATCH v2] Improve ptrace-error detection on Linux targets To: Sergio Durigan Junior 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> Cc: GDB Patches , Eli Zaretskii , Ruslan Kabatsayev From: Pedro Alves Message-ID: <587b2e6b-15ec-0ba1-f425-82ec45eb4ca7@redhat.com> Date: Wed, 04 Sep 2019 20:35:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <87d0gfrewj.fsf@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-09/txt/msg00041.txt.bz2 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? You could start gdbserver with the restrictions off (like a long lived daemon), and then while gdbserver is running enable restrictions, I suppose. Thanks, Pedro Alves