From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 42323 invoked by alias); 19 Aug 2019 18:26:27 -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 42315 invoked by uid 89); 19 Aug 2019 18:26:27 -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=equally 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; Mon, 19 Aug 2019 18:26:25 +0000 Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (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 5663211A17 for ; Mon, 19 Aug 2019 18:26:24 +0000 (UTC) Received: by mail-wr1-f72.google.com with SMTP id v15so5676616wrg.13 for ; Mon, 19 Aug 2019 11:26:24 -0700 (PDT) Received: from ?IPv6:2001:8a0:f913:f700:4c97:6d52:2cea:997b? ([2001:8a0:f913:f700:4c97:6d52:2cea:997b]) by smtp.gmail.com with ESMTPSA id c8sm15507102wrn.50.2019.08.19.11.26.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Aug 2019 11:26:21 -0700 (PDT) Subject: Re: [PATCH] Improve ptrace-error detection on Linux targets To: Sergio Durigan Junior , GDB Patches References: <20190819032918.3536-1-sergiodj@redhat.com> From: Pedro Alves Message-ID: Date: Mon, 19 Aug 2019 18:26: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: <20190819032918.3536-1-sergiodj@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-08/txt/msg00417.txt.bz2 Two comments on implementation, that I think apply equally to the new version you're working on as well: #1 - A target method (target_ptrace_me_fail_reason) looks like the wrong place to put this, to me. As I understand it, the core of gdb isn't ever calling the target_ptrace_me_fail_reason. This is all code that is implementation detail of the Linux target implementation. I'd prefer some other way to address this. An idea would be to have a function pointer in inf-ptrace.c that defaults to an implementation that returns the empty string: // in inf-ptrace.c static std::string default_inf_ptrace_me_fail_reason (int err) { return {}; } std::string (*inf_ptrace_me_fail_reason) (int err) = default_inf_ptrace_me_fail_reason; // in inf-ptrace.h extern std::string (*inf_ptrace_me_fail_reason) (int err); And then in linux-nat.c:_initialize_linux_nat, you'd override the implementation, like: std::string linux_ptrace_me_fail_reason (int err) { ... } void _initialize_linux_nat () { ... inf_ptrace_me_fail_reason = linux_ptrace_me_fail_reason; } Note I'm not suggesting anything with virtual methods before of the next point. #2 - What about gdbserver? Don't we want the same nice error messages in gdbserver? See gdbserver/linux-low.c:linux_ptrace_fun. This would suggest putting that linux_ptrace_me_fail_reason function in gdb/nat/ so that it would be used by gdbserver too. Thanks, Pedro Alves