From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32265 invoked by alias); 12 Feb 2016 16:08:59 -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 32246 invoked by uid 89); 12 Feb 2016 16:08:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= 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, 12 Feb 2016 16:08:57 +0000 Received: from svr-orw-fem-03.mgc.mentorg.com ([147.34.97.39]) by relay1.mentorg.com with esmtp id 1aUGH8-0002oW-FH from Luis_Gustavo@mentor.com ; Fri, 12 Feb 2016 08:08:54 -0800 Received: from [172.30.0.195] (147.34.91.1) by svr-orw-fem-03.mgc.mentorg.com (147.34.97.39) with Microsoft SMTP Server id 14.3.224.2; Fri, 12 Feb 2016 08:08:53 -0800 Reply-To: Luis Machado Subject: Re: [PATCH] Remote debugging without a binary (regression) References: <1455200365-5270-1-git-send-email-lgustavo@codesourcery.com> <56BDFA73.9000001@redhat.com> To: Pedro Alves , CC: From: Luis Machado Message-ID: <56BE038E.3060406@codesourcery.com> Date: Fri, 12 Feb 2016 16:08: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: <56BDFA73.9000001@redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00417.txt.bz2 On 02/12/2016 01:29 PM, Pedro Alves wrote: > On 02/11/2016 02:19 PM, Luis Machado wrote: > >> gdb/ChangeLog: >> >> 2016-02-11 Luis Machado >> >> * remote.c (remote_add_inferior): Guard block that can throw >> errors. > > So the question is: why guard this call, and not the others? > > E.g., I'd think that failing to find the executable in the sysroot > shouldn't error out of "attach" either. I did not exercise that, but did not discard it either. I was attempting to solve one problem at a time. There may be a failure there too. If you're attempting to attach to a remote process via a remote gdbserver, then GDB is already connected to gdbserver by the time it issues a vAttach request, no? If so, then it is not as problematic as not being able to connect to the target at all, but still wrong. In any case, GDB should honor the user option of not using a symbol file at all for debugging processes that are already running.