From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66212 invoked by alias); 24 Jul 2015 02:39:44 -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 66201 invoked by uid 89); 24 Jul 2015 02:39:43 -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,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 24 Jul 2015 02:39:41 +0000 Received: from svr-orw-fem-03.mgc.mentorg.com ([147.34.97.39]) by relay1.mentorg.com with esmtp id 1ZISte-0004cs-7P from Sandra_Loosemore@mentor.com for gdb@sourceware.org; Thu, 23 Jul 2015 19:39:38 -0700 Received: from [IPv6:::1] (147.34.91.1) by svr-orw-fem-03.mgc.mentorg.com (147.34.97.39) with Microsoft SMTP Server id 14.3.224.2; Thu, 23 Jul 2015 19:39:37 -0700 Message-ID: <55B1A4FC.9010403@codesourcery.com> Date: Fri, 24 Jul 2015 02:39:00 -0000 From: Sandra Loosemore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: "gdb@sourceware.org" Subject: Re: GDB now takes 4 minutes to start up with remote gdbserver target References: <55B1768E.9090309@codesourcery.com> In-Reply-To: <55B1768E.9090309@codesourcery.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-07/txt/msg00039.txt.bz2 On 07/23/2015 05:19 PM, Sandra Loosemore wrote: > > [snip] > > Is this really appropriate and user-friendly default behavior? Are > users really expected to wait 4 minutes for GDB to start up whenever > they debug a program on a remote target now? :-( > > It is definitely the vFile traffic that is slowing things down.... it > comes back from the "c" command instantaneously if I disable those packets. Some further observations: (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. (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. (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). (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. 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? -Sandra