From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 102694 invoked by alias); 28 Jul 2015 22:14:15 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 102680 invoked by uid 89); 28 Jul 2015 22:14:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 28 Jul 2015 22:14:13 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 8BFFC19F39E; Tue, 28 Jul 2015 22:14:12 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t6SMEAaU016337; Tue, 28 Jul 2015 18:14:11 -0400 Message-ID: <55B7FEB2.9050608@redhat.com> Date: Tue, 28 Jul 2015 22:14:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Doug Evans , Gary Benson CC: Sandra Loosemore , "gdb@sourceware.org" Subject: Re: GDB now takes 4 minutes to start up with remote gdbserver target References: <55B1768E.9090309@codesourcery.com> <55B1A4FC.9010403@codesourcery.com> <20150724085244.GB22673@blade.nx> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-07/txt/msg00075.txt.bz2 On 07/28/2015 05:54 PM, Doug Evans wrote: > On Fri, Jul 24, 2015 at 1:52 AM, Gary Benson 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