From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 73183 invoked by alias); 28 Feb 2020 20:35:19 -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 73175 invoked by uid 89); 28 Feb 2020 20:35:19 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=thinks, H*f:sk:a24ae84, H*i:sk:a24ae84 X-HELO: us-smtp-delivery-1.mimecast.com Received: from us-smtp-2.mimecast.com (HELO us-smtp-delivery-1.mimecast.com) (207.211.31.81) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 28 Feb 2020 20:35:17 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1582922116; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1rBGF0zj0/8iPMXgsucOF69BP6Dk+HUdmQ4ozg3YV5k=; b=TxokRT9j9ThsssQnH+BwHnhZQqUuIaw8ijRkTchwQWimq5rv4oOimq1uIreGbNeJwFWkkI 2zHPv73yvHu1XECsdKI12uXtS/9XfqZO0A2m/dsfEpY2lKvIg9C5Q/cI74gnS9WRixumEm W1UhzLhLQ0JvEnqj4WaLRHZNRUFwcrg= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-179-Pkb6YhwPPH-Qgv9ChTnO_A-1; Fri, 28 Feb 2020 15:35:06 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 679F413F6; Fri, 28 Feb 2020 20:35:05 +0000 (UTC) Received: from localhost (unused-10-15-17-54.yyz.redhat.com [10.15.17.54]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2376992D00; Fri, 28 Feb 2020 20:35:05 +0000 (UTC) From: Sergio Durigan Junior To: Pedro Alves Cc: Tom Tromey , GDB Patches , Eli Zaretskii , Ruslan Kabatsayev Subject: Re: [PATCH 2/6] Don't reset errno/bfd_error on 'throw_perror_with_name' References: <20190926042155.31481-1-sergiodj@redhat.com> <20200226200542.746617-1-sergiodj@redhat.com> <20200226200542.746617-3-sergiodj@redhat.com> <87wo86ivbu.fsf@tromey.com> Date: Fri, 28 Feb 2020 20:35:00 -0000 In-Reply-To: (Pedro Alves's message of "Fri, 28 Feb 2020 20:06:03 +0000") Message-ID: <87k146pi13.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg01075.txt.bz2 On Friday, February 28 2020, Pedro Alves wrote: > On 2/28/20 3:29 PM, Tom Tromey wrote: >>>>>>> "Sergio" =3D=3D Sergio Durigan Junior writes: >>=20 >> Sergio> Since this hunk may be a bit controversial, I decided to split i= t into >> Sergio> a separate patch. This is going to be needed by the ptrace-error >> Sergio> feature; GDB will need to be able to access the value of errno e= ven >> Sergio> after a call to our 'perror'-like functions. >>=20 >> I'm in favor of this. The existing code seems pretty ugly. > > I'm not sure in favor of relying on errno being preserved from > throw site to catch site, with potentially multiple try/catch hops > in between. Sergio, can you point out exactly how you're > intending to use that? Yeah. I caught this problem when I was testing to see if GDB would print the ptrace fail reason when trying (unsuccessfully) to attach to a process. The call stack looks like: linux_nat_target::attach | |--> inf_ptrace_target::attach # where ptrace fails | |--> throw_perror_with_name # where errno is set to 0 When 'throw_perror_with_name' calls 'error', 'linux_nat_target::attach' catches the exception and tries to print the reason: try { inf_ptrace_target::attach (args, from_tty); } catch (const gdb_exception_error &ex) { int saved_errno =3D errno; pid_t pid =3D parse_pid_to_attach (args); std::string reason =3D linux_ptrace_attach_fail_reason (pid, saved_er= rno); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^ if (!reason.empty ()) throw_error (ex.error, "warning: %s\n%s", reason.c_str (), ex.what ()); else throw_error (ex.error, "%s", ex.what ()); } However, at this point errno is already 0, so the function can't determine the exact reason for the ptrace failure. In fact, because errno =3D 0, 'linux_ptrace_attach_fail_reason' doesn't print anything, because it thinks everything is OK! IMO, it doesn't make sense to have errno =3D 0 while you're handling an exception (which, in this case, was caused exactly because a syscall failed, and so we expect errno to be different than 0). Thanks, --=20 Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/