Re: [PATCH] Remote debugging without a binary (regression)

[Luis Machado <lgustavo@codesourcery.com>]

On 02/11/2016 02:35 PM, Gary Benson wrote:
> 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?

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?