Re: GDB now takes 4 minutes to start up with remote gdbserver target

[Gary Benson <gbenson@redhat.com>]

Sandra Loosemore wrote:
> On 07/28/2015 03:25 AM, Gary Benson wrote:
> > Ok, here goes...
> > 
> >   * From a user's perspective GDB is magically prefixing *some*
> >     executable and shared library filenames with "target:".
> > 
> >   * From a developer's perspective this magic prefixing is implemented
> >     by having the string "target:" as the default sysroot.
> > 
> > My proposal is to make the default sysroot be "" again, and add the
> > prefix in solib_find_1 if certain conditions are met, specifically:
> > 
> >   * Executable filenames get prefixed with "target:" iff:
> >       Automatic "target:" prefixing is enabled
> >       AND gdb_sysroot is ""
> >       AND the filesystem is nonlocal
> > 
> >   * Shared library filenames get prefixed with "target:" iff:
> >       Automatic "target:" prefixing is enabled
> >       AND gdb_sysroot is ""
> >       AND the filesystem is nonlocal
> >       AND exec_filename starts with "target:"
> 
> Can you explain what "the filesystem is nonlocal" means?  Which
> filesystem?  Nonlocal relative to the host or the target?  And what
> qualifies as nonlocal -- e.g. are NFS or SSHFS mounts nonlocal?

It refers to the method GDB must use to access inferior files.
If GDB can access them using standard open/read/pread/write/unlink
calls then the (inferior's) filesystem is local (to GDB).
So NFS or SSHFS mounts are local in this sense.

Remote targets have nonlocal filesystems because GDB must access
them using special calls.

Inferiors running in containers also have nonlocal filesystems
because, even though the code is running on the same system, the
inferior has a different filesystem.  open("/usr/bin/python") in
the inferior will get a different file to open("/usr/bin/python")
in GDB.

Cheers,
Gary

-- 
http://gbenson.net/