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

[Sandra Loosemore <sandra at codesourcery dot com>]

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