From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 109195 invoked by alias); 28 Jul 2015 16:55:07 -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 109180 invoked by uid 89); 28 Jul 2015 16:55:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ig0-f182.google.com Received: from mail-ig0-f182.google.com (HELO mail-ig0-f182.google.com) (209.85.213.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 28 Jul 2015 16:55:05 +0000 Received: by iggf3 with SMTP id f3so129665800igg.1 for ; Tue, 28 Jul 2015 09:55:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=IAvceXFSS6EWlg9ZsgUIa04XV8YvRkLXxNuBvvoTBq4=; b=Cmij5ZKcvARKQPpiHQ7XLzqxXfiqQuIAMhdYNheJGTu1fm1ClQRowGZtjJYxG+5Mlq fGpFbUszGLbifgeetrfiO+Uh3+QdijyJiu9oGscXgT8EPZ79M3ixfJyiGKwjLQI0h0+d WrC72f6NnbIVJkL2pv+8kH9tAPOpGg14aFmovukYlcNOEx3sfhMAYr9oDQqe89Xzbjdn qMFc75HqUcHD+zFPIelWJoigtbwglgCxBlFlPdgXvDM+3SxGz60snS+JJzcuprF9CGNV wK/uIkqo1VILJVvp1qmOMm0xl7z2mdS01pCFK+gY6Y+cGaw9n0x0ktCVtS+BILnvfqrx Xe5A== X-Gm-Message-State: ALoCoQmpXX3moRoxram1vzMdLYO+JzJGA6TyJfKvpQrxGnGc8rCcHPEKBxTkVQIedeNOZYiFVVRj X-Received: by 10.50.66.129 with SMTP id f1mr8674891igt.7.1438102502997; Tue, 28 Jul 2015 09:55:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.93.102 with HTTP; Tue, 28 Jul 2015 09:54:23 -0700 (PDT) In-Reply-To: <20150724085244.GB22673@blade.nx> References: <55B1768E.9090309@codesourcery.com> <55B1A4FC.9010403@codesourcery.com> <20150724085244.GB22673@blade.nx> From: Doug Evans Date: Tue, 28 Jul 2015 16:55:00 -0000 Message-ID: Subject: Re: GDB now takes 4 minutes to start up with remote gdbserver target To: Gary Benson Cc: Sandra Loosemore , "gdb@sourceware.org" Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-07/txt/msg00067.txt.bz2 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. >> 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.