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.