GDB now takes 4 minutes to start up with remote gdbserver target
Sandra Loosemore
sandra@codesourcery.com
Fri Jul 24 13:59:00 GMT 2015
On 07/24/2015 02:52 AM, Gary Benson wrote:
>
> A large part of the motivation for these patches was to automate as
> much as possible so users did not have to tell GDB stuff it could
> figure out itself. Rather than reverting (the nuclear option!)
> how about we see if we can make GDB handle this.
>
> How were you debugging before these series went in? Without symbols?
> If you'd started GDB with "file" and "set sysroot" commands to set up
> your environment the whole remote-fetch should not have happened.
I am passing the executable to GDB on the command line. The executable
is linked with explicit -Wl,-dynamic-linker= and -Wl,-rpath options
pointing to a sysroot that is NFS-mounted on the remote target at the
same pathname as on the host system. (This is our normal automated test
configuration here, BTW.... I was trying to investigate why mainline
GDB testing now takes 12 hours versus 38 minutes for our last stable
release, and quickly realized that GDB's current behavior is going to be
totally unacceptable for interactive use as well.)
The user documentation we at Mentor distribute with our toolchains that
explains sysroots says that you only need to do "set sysroot" in the
debugger if you are interested in debugging shared libraries or
multi-threaded applications, *and* the remote sysroot pathname is not
valid on the host system. Neither of these things applies to what I was
trying to do. Plus, generally speaking, if you fail to do "set sysroot"
in older GDB versions, application debugging still works even if there
is a mismatch in the sysroot pathnames between host and target.... you
just get some messages now and then about how GDB couldn't find some
shared library symbols, and suggesting that you try "set sysroot".
What I find particularly confusing is that continuing to main doesn't
seem like a user action that requires information from the sysroot at
all. I have not set any breakpoints in shared libraries, I'm not trying
to backtrace through a library call, and I haven't requested that GDB
stop on solib events. Why does GDB need to transfer these files from
the target at all if the user is not interested in them?
> I'll look into some combination of making the remote transfer
> interruptable, and issuing a warning during slow transfers, to
> see if something like that could work. Could you update the
> manual to add the information that you would have like to have
> found there?
I'd rather that we fix GDB to "just work", as it used to do, rather than
have to document workarounds for this breakage.
-Sandra
More information about the Gdb
mailing list