From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 34029 invoked by alias); 28 Feb 2020 16:36:47 -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 34021 invoked by uid 89); 28 Feb 2020 16:36:47 -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*i:sk:87wo86i, H*f:sk:87wo86i 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 16:36:45 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1582907804; 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=8XkV94tHoY4F3rxTEz6Ga8DkziqypH+8OfipxaJ9lpI=; b=PfxNY3yS+YfpoU8UIsNuCNtmmWZmGMhRoLDFQA5DbgjnhRog712l6wwLpb6W7Edf8ONHbJ pgRr/NmEhCFJfe2HbvpLGsZsix8nNCOoEwoVsQOPzKgQ5lNv1mtQdnYsC1tXd9FMxqlfPe hbThHYu8mmGbTMH03k+isvpKeVJyN94= 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-363-mMwbtz_fNOiZK6J0fzKMzQ-1; Fri, 28 Feb 2020 11:36:38 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 19CB0800D48; Fri, 28 Feb 2020 16:36:37 +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 C65D41CB; Fri, 28 Feb 2020 16:36:36 +0000 (UTC) From: Sergio Durigan Junior To: Tom Tromey Cc: GDB Patches , Pedro Alves , 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 16:36:00 -0000 In-Reply-To: <87wo86ivbu.fsf@tromey.com> (Tom Tromey's message of "Fri, 28 Feb 2020 08:29:41 -0700") Message-ID: <875zfqr7mz.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/msg01062.txt.bz2 On Friday, February 28 2020, Tom Tromey wrote: >>>>>> "Sergio" =3D=3D Sergio Durigan Junior writes: > > 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-error > Sergio> feature; GDB will need to be able to access the value of errno ev= en > Sergio> after a call to our 'perror'-like functions. > > I'm in favor of this. The existing code seems pretty ugly. > > I'd imagine it's unlikely that any caller would rely on this. > If it tested cleanly then that is good enough for me. As far as I have tested (buildbot and locally), everything is OK. > Sergio> Another small hunk is the one that saves/restores errno on gdbser= ver's > Sergio> 'perror_with_name', but this one is pretty trivial, I think. > > I didn't understand why this one was needed. > Does safe_strerror reset errno? Maybe a comment would be in order. Ah, no, safe_strerror doesn't reset errno. As I explained in the commit message, it is not allowed to do so. The reason I decided to explicitly save/restore errno is because I wanted to make sure that we (also explicitly) follow the same rules for both GDB and gdbserver perror functions. But now I'm left thinking that I should have proposed the same thing for 'throw_perror_with_name'... Anyway, I'm fine with removing the save/restore from gdbserver's perror. I'll also remove the reference to it in the commit message. 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/