From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 33107 invoked by alias); 11 Feb 2016 17:06:35 -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 33079 invoked by uid 89); 11 Feb 2016 17:06:34 -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=symbolless, symbol-less, transfering, carry 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; Thu, 11 Feb 2016 17:06:32 +0000 Received: from svr-orw-fem-03.mgc.mentorg.com ([147.34.97.39]) by relay1.mentorg.com with esmtp id 1aTuhJ-0006Na-QB from Luis_Gustavo@mentor.com ; Thu, 11 Feb 2016 09:06:29 -0800 Received: from [172.30.9.173] (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; Thu, 11 Feb 2016 09:06:29 -0800 Reply-To: Luis Machado Subject: Re: [PATCH] Remote debugging without a binary (regression) References: <1455200365-5270-1-git-send-email-lgustavo@codesourcery.com> <20160211163510.GA21352@blade.nx> To: Gary Benson CC: From: Luis Machado Message-ID: <56BCBF8F.8040601@codesourcery.com> Date: Thu, 11 Feb 2016 17:06: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: <20160211163510.GA21352@blade.nx> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00376.txt.bz2 On 02/11/2016 02:35 PM, Gary Benson wrote: > 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? No. The sysroot being anything other than "target:" is needed is order to prevent gdbserver from transfering the files over (too slow). Plus, i'm not loading any symbol file on GDB's side. So i'm trying to connect to a gdbserver running on a remote system with a separate filesystem. gdbserver will now report the full path to the binary on the remote end via the new qXfer:exec-file packet, even if i force the sysroot to be empty. In summary, GDB (running on a local machine) is attempting to use that path provided by qXfer:exec-file to open a symbol file that only exists on the remote end's filesystem, not in the local filesystem where GDB is running. If GDB fails to locate that file, it will drop the connection due to a error that is thrown from within exec_file_locate_attach and its callees. The correct behavior is for GDB to ignore the lack of a symbol file and carry on connecting to the remote target, allowing a symbol-less debugging session. Does that make it clear?