From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 103402 invoked by alias); 19 Feb 2016 10:33:11 -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 103379 invoked by uid 89); 19 Feb 2016 10:33:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=overlap, cuts, Backtrace, our X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 19 Feb 2016 10:33:08 +0000 Received: from svr-orw-fem-06.mgc.mentorg.com ([147.34.97.120]) by relay1.mentorg.com with esmtp id 1aWiMz-0005va-Du from Luis_Gustavo@mentor.com ; Fri, 19 Feb 2016 02:33:05 -0800 Received: from [172.30.0.169] (147.34.91.1) by SVR-ORW-FEM-06.mgc.mentorg.com (147.34.97.120) with Microsoft SMTP Server id 14.3.224.2; Fri, 19 Feb 2016 02:33:05 -0800 Reply-To: Luis Machado Subject: Re: [PATCH] Fix logic in exec_file_locate_attach References: <56BDF92B.50107@redhat.com> <1455815129-14795-1-git-send-email-gbenson@redhat.com> <56C5FF48.3050804@redhat.com> <20160219102447.GA29870@blade.nx> To: Gary Benson , Pedro Alves CC: From: Luis Machado Message-ID: <56C6EF5A.8080906@codesourcery.com> Date: Fri, 19 Feb 2016 10:33:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160219102447.GA29870@blade.nx> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00585.txt.bz2 On 02/19/2016 08:24 AM, Gary Benson wrote: > Pedro Alves wrote: >> On 02/18/2016 05:05 PM, Gary Benson wrote: >>> * exec.c (exec_file_locate_attach): Throw error if >>> exec_file_find fails to locate the main executable. >> >> This goes back to: >> https://sourceware.org/ml/gdb-patches/2016-02/msg00413.html >> >> Why is this an error, that even makes us stop the attach process >> halfway, if the case when we don't know the file name is completely >> silent? : > > Hmmm, I was trying to fix a test failure, but looking at it with fresh > eyes this morning it would've been better to fix up that test as the > resulting state is more usable without a throw. This is with throw: > > (gdb) set sysroot /whatever > (gdb) attach 31954 > Attaching to process 31954 > ../attach-bad-sysroot: in sysroot "/whatever": No such file or directory. > (gdb) bt > #0 0xb54aca20 in ?? () > Backtrace stopped: Cannot access memory at address 0x25ae1df8 > (gdb) > > This is without throw: > > (gdb) set sysroot /whatever > (gdb) attach 31954 > Attaching to process 31954 > warning: Could not load vsyscall page because no executable was specified > try using the "file" command first. > 0x00000039b54aca20 in ?? () > (gdb) bt > #0 0x00000039b54aca20 in ?? () > #1 0x00000039b54ac8b0 in ?? () > #2 0x0000000000000000 in ?? () > (gdb) > > So without the throw you can backtrace. Also, not throwing will I > think fix things for Luis without adding TRY..CATCH in remote.c. > I'll rework and resubmit. For the record, i'm re-working my previous patch to handle the case of native attaches too, when the file access problem cuts the attachment process halfway through (regardless of sysroot use policies). I'm playing around with the TRY/CATCH block inside exec_file_locate_attach as opposed to taking care of its callers (in remote.c and infcmd.c). Currently i'm checking for regressions and writing a testcase. I just want to make sure our changes don't overlap in terms of logic.