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

[Gary Benson <gbenson@redhat.com>]

Sandra Loosemore wrote:
> (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.

The manual says this:

  If @var{path} starts with the sequence @file{target:} and the target
  system is remote then @value{GDBN} will retrieve the target binaries
  from the remote system.

It doesn't mention in the manual that this is the default, though it
is documented in NEWS:

  * Directory names supplied to the "set sysroot" commands may be
    prefixed with "target:" to tell GDB to access shared libraries from
    the target system, be it local or remote.  This replaces the prefix
    "remote:".  The default sysroot has been changed from "" to
    "target:".  "remote:" is automatically converted to "target:" for
    backward compatibility.

  * The system root specified by "set sysroot" will be prepended to the
    filename of the main executable (if reported to GDB as absolute by
    the operating system) when starting processes remotely, and when
    attaching to already-running local or remote processes.

  * GDB now supports automatic location and retrieval of executable
    files from remote targets.  Remote debugging can now be initiated
    using only a "target remote" or "target extended-remote" command
    (no "set sysroot" or "file" commands are required).  See "New remote
    packets" below.

> (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.

Understood.

> (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).

This is kind of a shortcoming of GDB in general.  There was a similar
issue relating to tab-completion in programs with lots of symbols:

  https://sourceware.org/bugzilla/show_bug.cgi?id=11920

I don't have a good solution for this.

> (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.

That's not great.

> 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?

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'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?

Thanks,
Gary

-- 
http://gbenson.net/