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

[Doug Evans <dje at google dot com>]

On Fri, Jul 24, 2015 at 1:52 AM, Gary Benson <gbenson@redhat.com> wrote:
>> (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.

I'm sure there are fine solutions.
The problem is getting gdb to a point where
good solutions fit in easily, without having to
do something specific for each case.

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

Being one of my pet peeves, I'm always on the lookout for examples,
hoping to raise awareness.
Is this another case of gdb trying to be "clever"
with no workaround when it's not what one wants?

ref: https://sourceware.org/ml/gdb-patches/2015-07/msg00767.html

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

I think just making things interruptable is insufficient.
We need to make it easy and obvious how to just not start these
transfers at all.