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

[Pedro Alves <palves@redhat.com>]

On 07/28/2015 05:54 PM, Doug Evans wrote:
> 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.

I agree.  I worry much about lots of "smartness" at
the last minute, and then be stuck with it.  The "target:" sysroot is
simple to explain and reason about.  The new proposal, not so much.
Also, with Aleksandar/Jan's gdbserver build-id validation series
in place, we may be able to come up with a different/better solution.

If resolving the interruptability and adding a suggestive warning
is deemed insufficient resolution (though I think we should try it
first), then I think it's too late to add too much magic, and we should
change the default sysroot back to "" by default.  Users can still then
put "set sysroot target:" in .gdbinit with 7.10, and we can continue
addressing identified issues until "target:" (or something around it)
can be made the default, on master.

(Another idea to build on top of this all to minimize downloads is
to have a gdb-side cache of remote file chunks, that persists
across gdb invocations.)

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

I agree.

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

Agreed.

Thanks,
Pedro Alves