From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 129691 invoked by alias); 2 Mar 2020 20:07:17 -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 129683 invoked by uid 89); 2 Mar 2020 20:07:16 -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=H*f:sk:87wo86i, errno, controversial, OK X-HELO: us-smtp-1.mimecast.com Received: from us-smtp-delivery-1.mimecast.com (HELO us-smtp-1.mimecast.com) (205.139.110.120) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 02 Mar 2020 20:07:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1583179633; 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=hW+9HYMvzJ+VUBiLiiMSGu6Fjzzg428GK4Vjp/SjB/w=; b=jCAHZxsIpH+hWhokFyRMdRq14JEXhqQx15w3gohnCYmKH9Zg3nwwFArwPfyIvbbpnPEw9o i/cZrYsbMlypUYxIIGW+yacDleKCEHfDZB9oTqXKhlJJvl46QvVDdqjGsBgTJQYkur1EkV 4Zder5WWDDsrL52IqsPZydDTjZNVFjs= 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-464-1G9CA1bnMXmDojVTQgDh5Q-1; Mon, 02 Mar 2020 15:07:07 -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 C763E10CE78C; Mon, 2 Mar 2020 20:07:06 +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 752EC73867; Mon, 2 Mar 2020 20:07:06 +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> <87k146pi13.fsf@redhat.com> <89e47bf5-d5c8-849d-e345-9b79306418f8@redhat.com> Date: Mon, 02 Mar 2020 20:07:00 -0000 In-Reply-To: <89e47bf5-d5c8-849d-e345-9b79306418f8@redhat.com> (Pedro Alves's message of "Fri, 28 Feb 2020 21:11:23 +0000") Message-ID: <87r1yah66t.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-03/txt/msg00043.txt On Friday, February 28 2020, Pedro Alves wrote: > On 2/28/20 8:35 PM, Sergio Durigan Junior wrote: >> On Friday, February 28 2020, Pedro Alves wrote: >>=20 >>> On 2/28/20 3:29 PM, Tom Tromey wrote: >>>>>>>>> "Sergio" =3D=3D Sergio Durigan Junior write= s: >>>> >>>> Sergio> Since this hunk may be a bit controversial, I decided to split= it into >>>> Sergio> a separate patch. This is going to be needed by the ptrace-er= ror >>>> Sergio> feature; GDB will need to be able to access the value of errno= even >>>> Sergio> after a call to our 'perror'-like functions. >>>> >>>> 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? >>=20 >> 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. >>=20 >> The call stack looks like: >>=20 >> linux_nat_target::attach >> | >> |--> inf_ptrace_target::attach # where ptrace fails >> | >> |--> throw_perror_with_name # where errno is set to 0 >>=20 >> When 'throw_perror_with_name' calls 'error', 'linux_nat_target::attach' >> catches the exception and tries to print the reason: >>=20 >> 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= _errno); >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^^^^ >>=20 >> if (!reason.empty ()) >> throw_error (ex.error, "warning: %s\n%s", reason.c_str (), >> ex.what ()); >> else >> throw_error (ex.error, "%s", ex.what ()); >> } >>=20 >> 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! >>=20 >> 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). > > This is bad design. Exception objects should be self contained > and not rely on global state to transfer information. OK. I implemented your idea, but I will wait until the other patches are reviewed so I can submit a v2 of the whole series. 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/