From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 35017 invoked by alias); 29 Aug 2019 19:48:24 -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 34892 invoked by uid 89); 29 Aug 2019 19:48:15 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.5 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; Thu, 29 Aug 2019 19:48:14 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9D716307D868; Thu, 29 Aug 2019 19:48:09 +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 6D7F76092D; Thu, 29 Aug 2019 19:48:09 +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> Date: Thu, 29 Aug 2019 19:48:00 -0000 In-Reply-To: <87mufrai1z.fsf@redhat.com> (Sergio Durigan Junior's message of "Thu, 29 Aug 2019 15:27:20 -0400") Message-ID: <87ftljah3a.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-08/txt/msg00651.txt.bz2 On Thursday, August 29 2019, I wrote: > On Thursday, August 29 2019, Pedro Alves wrote: > >>> - It reads the contents of "/proc/sys/kernel/yama/ptrace_scope" and >>> checks if it's different than 0. >>> >>> For each of these checks, if it succeeds, the user will see a message >>> informing about the restriction in place, and how it can be disabled. >>> For example, if "deny_ptrace" is enabled, the user will see: >>> >>> # gdb /bin/true >>> ... >>> Starting program: /usr/bin/true >>> warning: Could not trace the inferior process. >>> Error: >>> warning: ptrace: Permission denied >> >> Curious, that: >> >> warning: >> Error: >> warning: >> >> looks a bit odd, specifically the "Error:" line. Do you know where is >> that coming from? > > Not offhand; I'll investigate and come back with the results. So, the problem is with nat/fork-inferior.c:trace_start_error: void trace_start_error (const char *fmt, ...) { va_list ap; va_start (ap, fmt); warning ("Could not trace the inferior process.\nError: "); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ vwarning (fmt, ap); va_end (ap); gdb_flush_out_err (); _exit (0177); } /* See nat/fork-inferior.h. */ void trace_start_error_with_name (const char *string, const char *append) { trace_start_error ("%s: %s%s", string, safe_strerror (errno), append); } You can see that we're calling "warning", which puts a newline at the end of the string. I think it'd be best to just get rid of the "\nError: " suffix. We'd then have something like: Starting program: /usr/bin/true warning: Could not trace the inferior process. warning: ptrace: Permission denied .... WDYT? -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/