This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 0/2] Better handling of slow remote transfers
- From: Gary Benson <gbenson at redhat dot com>
- To: Sandra Loosemore <sandra at codesourcery dot com>
- Cc: Joel Brobecker <brobecker at adacore dot com>, Doug Evans <dje at google dot com>, Jan Kratochvil <jan dot kratochvil at redhat dot com>, gdb-patches <gdb-patches at sourceware dot org>, Pedro Alves <palves at redhat dot com>, André Pönitz <apoenitz at t-online dot de>, Paul Koning <Paul_Koning at dell dot com>
- Date: Tue, 18 Aug 2015 10:58:59 +0100
- Subject: Re: [PATCH 0/2] Better handling of slow remote transfers
- Authentication-results: sourceware.org; auth=none
- References: <001a11c301b0388ac5051d0c5ab8 at google dot com> <20150811185519 dot GA28644 at host1 dot jankratochvil dot net> <CADPb22TM42jGif4PqOgpvDxb7RhzS=vBgGJijcB7h9-3rCbH7A at mail dot gmail dot com> <20150811195943 dot GC22245 at adacore dot com> <20150812094831 dot GD11096 at blade dot nx> <20150814182648 dot GO22245 at adacore dot com> <55CE6AA3 dot 8000300 at codesourcery dot com> <20150816184913 dot GA2998 at adacore dot com> <20150817085310 dot GC25320 at blade dot nx> <55D1EE96 dot 9060202 at codesourcery dot com>
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/