From patchwork Thu Feb 11 14:19:25 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luis Machado X-Patchwork-Id: 10821 Received: (qmail 113442 invoked by alias); 11 Feb 2016 14:19:45 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 112893 invoked by uid 89); 11 Feb 2016 14:19:44 -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=locating, gary, Gary, transfered 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 14:19:39 +0000 Received: from svr-orw-fem-05.mgc.mentorg.com ([147.34.97.43]) by relay1.mentorg.com with esmtp id 1aTs5n-000267-Hi from Luis_Gustavo@mentor.com ; Thu, 11 Feb 2016 06:19:35 -0800 Received: from opsys.world.mentorg.com (147.34.91.1) by svr-orw-fem-05.mgc.mentorg.com (147.34.97.43) with Microsoft SMTP Server id 14.3.224.2; Thu, 11 Feb 2016 06:19:34 -0800 From: Luis Machado To: CC: Subject: [PATCH] Remote debugging without a binary (regression) Date: Thu, 11 Feb 2016 12:19:25 -0200 Message-ID: <1455200365-5270-1-git-send-email-lgustavo@codesourcery.com> MIME-Version: 1.0 X-IsSubscribed: yes 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 * remote.c (remote_add_inferior): Guard block that can throw errors. --- gdb/remote.c | 30 ++++++++++++++++++++++++++---- 1 file changed, 26 insertions(+), 4 deletions(-) diff --git a/gdb/remote.c b/gdb/remote.c index 6d56f19..3b63e9f 100644 --- a/gdb/remote.c +++ b/gdb/remote.c @@ -1789,10 +1789,32 @@ remote_add_inferior (int fake_pid_p, int pid, int attached, inf->attach_flag = attached; inf->fake_pid_p = fake_pid_p; - /* If no main executable is currently open then attempt to - open the file that was executed to create this inferior. */ - if (try_open_exec && get_exec_file (0) == NULL) - exec_file_locate_attach (pid, 1); + + /* exec_file_locate_attach may throw an error if the file cannot be + opened either locally or remotely. This happens when, for example, + GDB connects to a gdbserver that is running on a different + filesystem and the sysroot is set to non-target-based (no "target:"). + + Then GDB will neither load the binary from the target nor be able to + load a binary from the local filesystem (it may not exist in the local + filesystem in the same path as in the remote filesystem). + + Even without a binary, the remote-based debugging session should + continue normally instead of ending abruptly. */ + + TRY + { + /* If no main executable is currently open then attempt to + open the file that was executed to create this inferior. */ + if (try_open_exec && get_exec_file (0) == NULL) + exec_file_locate_attach (pid, 1); + } + CATCH (err, RETURN_MASK_ALL) + { + if (err.message != NULL) + warning ("%s", err.message); + } + END_CATCH return inf; }