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

On 07/23/2015 05:19 PM, Sandra Loosemore wrote:
>
> [snip]
>
> Is this really appropriate and user-friendly default behavior?  Are
> users really expected to wait 4 minutes for GDB to start up whenever
> they debug a program on a remote target now?  :-(
>
> It is definitely the vFile traffic that is slowing things down....  it
> comes back from the "c" command instantaneously if I disable those packets.

Some further observations:

(1) I don't see anything in the GDB manual to indicate that transferring 
files from the target back to the host is the default behavior for "set 
sysroot", nor do I see any kind of warning that this can be a very slow 
operation.

(2) I don't know how users are supposed to know that "set sysroot" is 
the source of this slowness, either.  There needs to be something in the 
section of the manual that discusses how to connect to a remote 
gdbserver target that tells you what to do if the default behavior is 
unacceptably slow.

(3) Once the "c" command is issued, there's nothing to inform the user 
exactly what GDB is doing or that this can be a very slow operation 
(e.g., with a progress bar).

(4) GDB doesn't respond to ^C during the 4 minutes it is doing whatever 
it's doing to transfer files.  It just sits there acting catatonic.

In absence of any other information, users are likely to come to the 
same conclusion I did -- that GDB and/or GDBserver are broken and just 
got wedged somewhere on startup.  I was knowledgeable enough about GDB 
internals to restart my session and do "set debug remote 1" prior to 
connecting so I could see the RSP traffic and get a clue where it was 
getting stuck; ordinary users would probably just give up in disgust, or 
complain to their toolchain vendor :-P that GDB is broken.

While I appreciate that this change may be useful in fixing a class of 
user problems, it is an incompatible change from past behavior and 
causes a whole different set of problems for users.  Can we please 
consider restoring the default for "set sysroot" to its previous behavior?

-Sandra