[PATCH] Remote debugging without a binary (regression)

[Gary Benson]

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
> <some_remote_filesystem_path/gdb.d/gdb.base/break: No such file or directory.
> --
> 
> 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: <some_remote_filesystem_path/gdb.d/gdb.base/break: No such file or directory.
> --
> 
> 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/