From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 100976 invoked by alias); 24 Jul 2015 08:52:48 -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 100964 invoked by uid 89); 24 Jul 2015 08:52:48 -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; Fri, 24 Jul 2015 08:52:46 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id A81BE8EAF6; Fri, 24 Jul 2015 08:52:45 +0000 (UTC) Received: from blade.nx (ovpn-116-19.ams2.redhat.com [10.36.116.19]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t6O8qiGn029355; Fri, 24 Jul 2015 04:52:45 -0400 Received: by blade.nx (Postfix, from userid 1000) id 4B1A8264A1D; Fri, 24 Jul 2015 09:52:44 +0100 (BST) Date: Fri, 24 Jul 2015 08:52:00 -0000 From: Gary Benson To: Sandra Loosemore Cc: "gdb@sourceware.org" Subject: Re: GDB now takes 4 minutes to start up with remote gdbserver target Message-ID: <20150724085244.GB22673@blade.nx> References: <55B1768E.9090309@codesourcery.com> <55B1A4FC.9010403@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55B1A4FC.9010403@codesourcery.com> X-IsSubscribed: yes X-SW-Source: 2015-07/txt/msg00042.txt.bz2 Sandra Loosemore wrote: > (1) I don't see anything in the GDB manual to indicate that > transferring files from the target back to the host is the default > behavior for "set sysroot", nor do I see any kind of warning that > this can be a very slow operation. The manual says this: If @var{path} starts with the sequence @file{target:} and the target system is remote then @value{GDBN} will retrieve the target binaries from the remote system. It doesn't mention in the manual that this is the default, though it is documented in NEWS: * Directory names supplied to the "set sysroot" commands may be prefixed with "target:" to tell GDB to access shared libraries from the target system, be it local or remote. This replaces the prefix "remote:". The default sysroot has been changed from "" to "target:". "remote:" is automatically converted to "target:" for backward compatibility. * The system root specified by "set sysroot" will be prepended to the filename of the main executable (if reported to GDB as absolute by the operating system) when starting processes remotely, and when attaching to already-running local or remote processes. * GDB now supports automatic location and retrieval of executable files from remote targets. Remote debugging can now be initiated using only a "target remote" or "target extended-remote" command (no "set sysroot" or "file" commands are required). See "New remote packets" below. > (2) I don't know how users are supposed to know that "set sysroot" > is the source of this slowness, either. There needs to be something > in the section of the manual that discusses how to connect to a > remote gdbserver target that tells you what to do if the default > behavior is unacceptably slow. Understood. > (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. > (4) GDB doesn't respond to ^C during the 4 minutes it is doing > whatever it's doing to transfer files. It just sits there acting > catatonic. That's not great. > In absence of any other information, users are likely to come to the > same conclusion I did -- that GDB and/or GDBserver are broken and > just got wedged somewhere on startup. I was knowledgeable enough > about GDB internals to restart my session and do "set debug remote > 1" prior to connecting so I could see the RSP traffic and get a clue > where it was getting stuck; ordinary users would probably just give > up in disgust, or complain to their toolchain vendor :-P that GDB is > broken. > > 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. 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? Thanks, Gary -- http://gbenson.net/