This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: GDB now takes 4 minutes to start up with remote gdbserver target
- From: Gary Benson <gbenson at redhat dot com>
- To: Sandra Loosemore <sandra at codesourcery dot com>
- Cc: Pedro Alves <palves at redhat dot com>, Paul_Koning at Dell dot com, gdb at sourceware dot org
- Date: Wed, 29 Jul 2015 11:00:46 +0100
- Subject: Re: GDB now takes 4 minutes to start up with remote gdbserver target
- Authentication-results: sourceware.org; auth=none
- References: <20150724085244 dot GB22673 at blade dot nx> <55B2444C dot 106 at codesourcery dot com> <2906903F-7478-4B9D-8A9A-A6256F8076EF at dell dot com> <20150724151148 dot GA18553 at blade dot nx> <FC7D3C21-A8E8-4316-8125-E9FCE152F5D0 at dell dot com> <55B26267 dot 4060905 at redhat dot com> <55B27348 dot 1020104 at codesourcery dot com> <20150727121454 dot GA15226 at blade dot nx> <20150728092507 dot GA28545 at blade dot nx> <55B79DD6 dot 1000200 at codesourcery dot 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/