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: Pedro Alves <palves at redhat 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>, Sandra Loosemore <sandra at codesourcery dot com>, André Pönitz <apoenitz at t-online dot de>, Paul Koning <Paul_Koning at dell dot com>
- Date: Wed, 12 Aug 2015 16:08:42 +0100
- Subject: Re: [PATCH 0/2] Better handling of slow remote transfers
- Authentication-results: sourceware.org; auth=none
- References: <55CB1B8D dot 6010501 at redhat dot com> <20150812103831 dot GA12792 at blade dot nx> <55CB2DF8 dot 2050506 at redhat dot com> <20150812123254 dot GA14726 at blade dot nx> <55CB4150 dot 6090807 at redhat dot com> <20150812130248 dot GA15429 at blade dot nx> <55CB4B74 dot 3070204 at redhat dot com> <20150812133825 dot GA25961 at blade dot nx> <55CB5119 dot 9070504 at redhat dot com> <55CB5BDA dot 3020904 at redhat dot com>
Pedro Alves wrote:
> On 08/12/2015 02:58 PM, Pedro Alves wrote:
> > GDB will usually cap the transfers to before they get to the
> > lower layers. E.g., look for 4096 in memory_xfer_partial,
> > target_read_alloc_1 and target_fileio_read_alloc_1.
> >
> > As this request is coming from the BFD side, we should probably
> > make remote_hostio_pread also cap the size of the vFile:pread
> > request. A reasonable number like a few KBs should not
> > introduce any noticeable slow down.
>
> But wait, I'm now confused -- isn't this a red herring? Since
> gdbserver is already limiting transfers to PBUFSIZE, this change
> should have no practical effect, right?
>
> How can BFD's large remote_hostio_pread result in large vFile:pread:
> packet responses then?
I think gdbserver is returning multiple packets but something in GDB
(getpkt_or_notif_sane_1?) is concatenating them together somehow.
Cheers,
Gary
--
http://gbenson.net/