From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) by sourceware.org (Postfix) with ESMTP id 72D2E38618B2 for ; Tue, 1 Sep 2020 02:04:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 72D2E38618B2 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-404-QlMdpJBTMjSSjGHqaNAJ2g-1; Mon, 31 Aug 2020 22:04:38 -0400 X-MC-Unique: QlMdpJBTMjSSjGHqaNAJ2g-1 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 CDEB48015A3 for ; Tue, 1 Sep 2020 02:04:37 +0000 (UTC) Received: from f32-m1.lan (ovpn-115-29.phx2.redhat.com [10.3.115.29]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B2F6C7DA3A for ; Tue, 1 Sep 2020 02:04:37 +0000 (UTC) Date: Mon, 31 Aug 2020 19:04:37 -0700 From: Kevin Buettner To: gdb-patches@sourceware.org Subject: Re: [PATCH] Work around incorrect/broken pathnames in NT_FILE note Message-ID: <20200831190437.35f7a035@f32-m1.lan> In-Reply-To: <0484421f-a3a6-a319-760f-a620c86385bb@palves.net> References: <20200807222044.2252664-1-kevinb@redhat.com> <0430a5a8-e5b5-d63e-047c-0d25fb5767ac@palves.net> <20200828202528.36adfec0@f32-m1.lan> <0484421f-a3a6-a319-760f-a620c86385bb@palves.net> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0.002 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2020 02:04:42 -0000 On Mon, 31 Aug 2020 15:50:07 +0100 Pedro Alves wrote: > Hi Kevin, > > On 8/29/20 4:25 AM, Kevin Buettner wrote: > > Hi Pedro, > > > > I've made all of the changes you suggested except for this one... > > > >>> @@ -227,6 +244,7 @@ core_target::build_file_mappings () > >>> > >>> if (bfd == nullptr || !bfd_check_format (bfd, bfd_object)) > >>> { > >>> + m_core_unavailable_mappings.emplace_back (start, end - start); > >>> /* If we get here, there's a good chance that it's due to > >>> an internal error. We issue a warning instead of an > >>> internal error because of the possibility that the > >> > >> Now that we're expecting to reach here, the comment about an internal > >> error seems stale. > > > > IMO, we'll (still) only reach the code in question due either to an > > internal error or due to the condition mentioned later in the comment. > > Bear in mind that we've already checked for the existence of the file > > and have even opened the file (though we're discarding the result) in > > the call to exec_file_find(). The test with accompanying warning message > > following the call to exec_file_find() should handle most if not all cases > > where the path name is bad / broken. > > > > The calls to bfd_openr() and bfd_check_format() _should_ be successful, > > but we still need to check the result, hence second block containing the > > comment and the warning, etc. > > > > I see, thanks. > > This version LGTM. > > Pedro Alves > Thanks for the reviews. I've pushed this version. Kevin