From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 38357 invoked by alias); 11 Feb 2016 16:35:16 -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 36796 invoked by uid 89); 11 Feb 2016 16:35:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 11 Feb 2016 16:35:14 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 9076B91EAF; Thu, 11 Feb 2016 16:35:12 +0000 (UTC) Received: from blade.nx (ovpn-116-100.ams2.redhat.com [10.36.116.100]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u1BGZBsH031779; Thu, 11 Feb 2016 11:35:12 -0500 Received: by blade.nx (Postfix, from userid 1000) id CD3EE264302; Thu, 11 Feb 2016 16:35:10 +0000 (GMT) Date: Thu, 11 Feb 2016 16:35:00 -0000 From: Gary Benson To: Luis Machado Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] Remote debugging without a binary (regression) Message-ID: <20160211163510.GA21352@blade.nx> References: <1455200365-5270-1-git-send-email-lgustavo@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1455200365-5270-1-git-send-email-lgustavo@codesourcery.com> X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00370.txt.bz2 Hi Luis, Luis Machado wrote: > cc-ing Gary. > > It looks like this is fallout from the changes that were added to > make GDB a bit smarter about locating the binary that is being > debugged. > > When one attempts to do gdbserver-based debugging in the same > machine/filesystem, there is no problem at all. > > If the user wants to have the files transfered over the wire, GDB > will handle it. If the user sets a local sysroot path and doesn't > want the file coming through the wire, GDB will use process > information to attempt to locate the binary in the local filesystem. > > Now, considering we have a GDB instance running on a local machine > and a gdbserver instance running on a remote machine with a > completely separate filesystem, having the sysroot set will prevent > the file from being downloaded. > > GDB will then attempt to be smart and locate the binary through the > path that is reported by gdbserver. This path is from the remote > filesystem though, so there is a chance this file won't even exist > in the local filesystem. > > In a normal native session (where we start the process from scratch) > this would result in a "No such file or directory" error. And that > is fine, because we really need a binary to get the process started. > > But with a local GDB plus a remote gdbserver on a different > filesystem, we will see the same error and the debugging session > will end abruptly, giving the user no chance of doing some debugging > without a symbol file. > > -- > Remote debugging using some_machine:12345 > -- > > I tracked this down to remote_add_inferior and its call to (mainly) > exec_file_locate_attach. This specific function will call other > functions that may throw an error, causing everything to stop dead > on its tracks. > > The following patch guards such a call to prevent those errors from > disrupting a potential debugging session, and display only a warning. > > -- > Remote debugging using some_machine:12345 > warning: -- > > I tried to come up with a valid testcase that would fail with a > local gdb/gdbserver combination, but it seems GDB is smart enough to > recognize a deleted binary with the help of /proc, thus foiling my > attempts. I don't have any fundamental objection to your patch but I'm not really sure I understand what's going on here. You have the sysroot set to some path that does not exist? What are you trying to do and what are you expecting to be able to do? What did GDB do before? Thanks, Gary -- http://gbenson.net/