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

Sandra Loosemore
2015-07-24T02:39:44Z

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