From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 51081 invoked by alias); 12 Feb 2016 10:59:48 -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 50918 invoked by uid 89); 12 Feb 2016 10:59:47 -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=H*r:Fri, disrupt, 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; Fri, 12 Feb 2016 10:59:38 +0000 Received: from svr-orw-fem-03.mgc.mentorg.com ([147.34.97.39]) by relay1.mentorg.com with esmtp id 1aUBRl-0007HW-EW from Luis_Gustavo@mentor.com ; Fri, 12 Feb 2016 02:59:33 -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 02:59:32 -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> <56BCBF8F.8040601@codesourcery.com> <20160212103144.GB12352@blade.nx> To: Gary Benson CC: From: Luis Machado Message-ID: <56BDBB0D.7030904@codesourcery.com> Date: Fri, 12 Feb 2016 10:59: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: <20160212103144.GB12352@blade.nx> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00402.txt.bz2 On 02/12/2016 08:31 AM, Gary Benson wrote: > Luis Machado wrote: >> On 02/11/2016 02:35 PM, Gary Benson wrote: >>> Luis Machado wrote: >>>> 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? > > I'm getting there, but I have a couple more questions: > > 1) What exactly are you setting sysroot to? Is it: > - the empty string > - a directory full of shared libraries but not the main executable > - an empty directory > - a non-existent directory? > It doesn't matter, as long as it is not "target:", meaning we really don't want to load files using the help of gdbserver. > 2) What exactly is the error being thrown within exec_file_locate_attach? > The one i mentioned above: /gdb.d/gdb.base/break: No such file or directory. This comes from exec_file_attach. In my specific case above, this is thrown from gdb/exec.c:268, a call to perror_with_name. if (scratch_chan < 0) perror_with_name (filename); It seems this was introduced with commit 1b6e6f5c7ffba559a681d11852acf38ef48dceff, with the addition of a call to exec_file_locate_attach from within remote_add_inferior. That unguarded call to exec_file_locate_attach doesn't look safe since its callees can throw errors and potentially disrupt a connection attempt. > FWIW I tried this (both on the same machine): > Doing so with both on the same machine/filesystem will not reproduce the problem, as i mentioned in my original post. GDB and gdbserver need to be on separate filesystems. > gdbserver :9999 /bin/ls > gdb -q -ex "set sysroot /whatever" -ex "target remote :9999" > > and got this: > > Reading symbols from /bin/ls...(no debugging symbols found)...done. > > which I think is an error: the sysroot is being ignored. > Isn't it being ignored because GDB managed to figure out the path and successfully open the symbol file? If it should honor the sysroot in that case, that looks like a different problem than the one i was originally chasing. There may be more bugs. :-) > Once again, I have no fundamental problem with your patch, but I want > to make sure we're not papering over some deeper issue. > > Thanks, > Gary >