This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: GDB now takes 4 minutes to start up with remote gdbserver target
- From: Gary Benson <gbenson at redhat dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Doug Evans <dje at google dot com>, Sandra Loosemore <sandra at codesourcery dot com>, "gdb at sourceware dot org" <gdb at sourceware dot org>, Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Date: Wed, 29 Jul 2015 11:39:48 +0100
- Subject: Re: GDB now takes 4 minutes to start up with remote gdbserver target
- Authentication-results: sourceware.org; auth=none
- References: <55B1768E dot 9090309 at codesourcery dot com> <55B1A4FC dot 9010403 at codesourcery dot com> <20150724085244 dot GB22673 at blade dot nx> <CADPb22S-yeRBtFCroWP6kdCQYXkmJuewwonKVXffGbfTYi5z6A at mail dot gmail dot com> <55B7FEB2 dot 9050608 at redhat dot com>
Pedro Alves wrote:
> 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.
Agreed.
I'm in no way pushing the series I posted, I made it more to turn
what was previously a thought experiment into something more concrete.
I should maybe have posted it as an RFC...
> Also, with Aleksandar/Jan's gdbserver build-id validation series in
> place, we may be able to come up with a different/better solution.
Yes. Jan told me he was considering changing sysroot to a multiple-
component path, with the default being something like "/:target:/".
This should work really nicely, but it only makes sense with build-id
validation (it's just too easy to get the wrong files otherwise).
I'm assuming we can cope with the fact that the separator ":" appears
in "target:" somehow :)
> 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.
I'm going to look at adding a warning.
Note that reverting the sysroot back to "" is not exactly zero-risk
given that GDB is now more aggressive in discovering executable
filenames from remote targets.
Cheers,
Gary
--
http://gbenson.net/