From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 56409 invoked by alias); 12 Feb 2016 10:31:49 -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 56389 invoked by uid 89); 12 Feb 2016 10:31:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=carry 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; Fri, 12 Feb 2016 10:31:47 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id E4E16C0A5166; Fri, 12 Feb 2016 10:31:45 +0000 (UTC) Received: from blade.nx (ovpn-116-100.ams2.redhat.com [10.36.116.100]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u1CAVirL007798; Fri, 12 Feb 2016 05:31:45 -0500 Received: by blade.nx (Postfix, from userid 1000) id 4212826430B; Fri, 12 Feb 2016 10:31:44 +0000 (GMT) Date: Fri, 12 Feb 2016 10:31:00 -0000 From: Gary Benson To: Luis Machado Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] Remote debugging without a binary (regression) Message-ID: <20160212103144.GB12352@blade.nx> References: <1455200365-5270-1-git-send-email-lgustavo@codesourcery.com> <20160211163510.GA21352@blade.nx> <56BCBF8F.8040601@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56BCBF8F.8040601@codesourcery.com> X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00400.txt.bz2 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? 2) What exactly is the error being thrown within exec_file_locate_attach? FWIW I tried this (both on the same machine): 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. 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 -- http://gbenson.net/