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: Pedro Alves <palves at redhat dot com>
- To: Gary Benson <gbenson 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:31: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> <20150812150841 dot GA20824 at blade dot nx>
On 08/12/2015 04:08 PM, Gary Benson wrote:
> 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.
No, getpkt_or_notif_sane_1 will return as soon as it has a single
packet, which should then be bubbling up the layers and reaching
gdb_bfd_iovec_fileio_pread. Something else is going on.
Either the QUIT is being lost/eaten, or ... hmm ... maybe the
SIGINT handler is set to remote.c:async_handle_remote_sigint
when the ctrl-c is typed, which means the ctrl-c doesn't
actually set_quit_flag()?
Thanks,
Pedro Alves