From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 43304 invoked by alias); 18 Aug 2015 09:59:03 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 43291 invoked by uid 89); 18 Aug 2015 09:59:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no 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, 18 Aug 2015 09:59:02 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id A252B90222; Tue, 18 Aug 2015 09:59:00 +0000 (UTC) Received: from blade.nx (ovpn-116-91.ams2.redhat.com [10.36.116.91]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t7I9wxEd019676; Tue, 18 Aug 2015 05:59:00 -0400 Received: by blade.nx (Postfix, from userid 1000) id 2407A2622CC; Tue, 18 Aug 2015 10:58:59 +0100 (BST) Date: Tue, 18 Aug 2015 09:59:00 -0000 From: Gary Benson To: Sandra Loosemore Cc: Joel Brobecker , Doug Evans , Jan Kratochvil , gdb-patches , Pedro Alves , =?iso-8859-1?Q?Andr=E9_P=F6nitz?= , Paul Koning Subject: Re: [PATCH 0/2] Better handling of slow remote transfers Message-ID: <20150818095858.GB9815@blade.nx> References: <001a11c301b0388ac5051d0c5ab8@google.com> <20150811185519.GA28644@host1.jankratochvil.net> <20150811195943.GC22245@adacore.com> <20150812094831.GD11096@blade.nx> <20150814182648.GO22245@adacore.com> <55CE6AA3.8000300@codesourcery.com> <20150816184913.GA2998@adacore.com> <20150817085310.GC25320@blade.nx> <55D1EE96.9060202@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55D1EE96.9060202@codesourcery.com> X-IsSubscribed: yes X-SW-Source: 2015-08/txt/msg00455.txt.bz2 Sandra Loosemore wrote: > On 08/17/2015 02:53 AM, Gary Benson wrote: > > It seems to me that being able to interrupt file transfers is > > polish. With the warning patch alone, users will see the warning > > and the hint about how to restore the previous default, which they > > can apply and continue as before. If they have to wait out a > > transfer then it will presumably only be once. I know some people > > use GDB on systems with 5,000+ shared libraries, and others use > > GDB on slow serial links, but I don't think anybody combines these > > cases. > > FYI, I am not debugging over a "slow serial link". I've been > testing this on an Altera 3c120 board (Nios II) with 10/100 > Ethernet; it NFS-mounts the sysroot under test and before now that > has worked fine with no obvious responsiveness issues. > > > So, would the warning+hint patch alone be enough? > > Is it really user-friendly to make the user either wait 4 minutes > of kill GDB through a separate terminal before they can act on the > hint? This user-friendliness argument is almost a straw man. Is it user-friendly to make the user wait 4 minutes before they can update their .gdbinit and continue as before? Probably not. Is it user-friendly to make the user set up NFS on the target or copy all the files across (and keep them synchronized)? Also probably not. Is it user friendly to expect users who want GDB to locate binaries for them to add "set sysroot target:" to their .gdbinit? Also probably not. Is it user friendly to expect users who want to use GDB across containers to add "set sysroot target:" to their .gdbinit? Also probably not. So lets leave user-friendliness to one side and talk about what's actually happening. For some reason, the Altera 3c120 board you are using is very much slower to transfer files over RSP than it is over NFS. For some reason, neither of the two QUIT patches I mailed work on your setup with this Altera 3c120 board you are using even though they work just fine on this x86_64 machine I am using. Your PandaBoard takes 8 seconds. That doesn't seem so bad to me. If this Altera board is the only one with the massive slowdown then I don't think we should delay 7.10 any further on this issue--and I certainly don't think we should lose the functionality that the default sysroot of "target:" brings. Thanks, Gary -- http://gbenson.net/