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 15:44:42 +0100
- Subject: Re: [PATCH 0/2] Better handling of slow remote transfers
- Authentication-results: sourceware.org; auth=none
- References: <CADPb22TM42jGif4PqOgpvDxb7RhzS=vBgGJijcB7h9-3rCbH7A at mail dot gmail dot com> <20150811195943 dot GC22245 at adacore dot com> <20150812094831 dot GD11096 at blade dot nx> <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>
On 08/12/2015 02:58 PM, Pedro Alves wrote:
> On 08/12/2015 02:38 PM, Gary Benson wrote:
>> Pedro Alves wrote:
>>> On 08/12/2015 02:02 PM, Gary Benson wrote:
>>>>>>>>>> I was only OK with trying to make transfers interruptible in the
>>>>>>>>>> branch assuming it was something non-invasive, like a missing
>>>>>>>>>> QUIT here and there.
>>>>>>>>
>>>>>>>> No, gdbserver sends the data in PBUFSIZ chunks, but GDB reads the
>>>>>>>> data a character at a time.
>>>>>>
>>>>>> Can you expand on this? What code is it that reads the data a
>>>>>> character at a time? What data is gdb getting at when it does that?
>>>> I was looking in getpkt_or_notif_sane_1, but I think maybe I misread
>>>> it. I'll get back to you on this...
>>>
>>> That's the very low level of RSP packets, which as you noted will
>>> have a reasonable cap. It sounds to me there's a loop somewhere in
>>> a higher layer that is missing a QUIT. E.g., we have quits
>>> in dwarf2read.c which allow interrupting reading big binaries,
>>> even if locally. So what is the higher level operation that
>>> gdb is doing when you try to interrupt, but can't?
>>
>> remote_hostio_pread. I'm trying to make remote_hostio_pread
>> interruptible. BFD is doing large remote_hostio_pread which
>> are resulting in large vFile:pread: packet responses.
>
> And what is BFD doing that ends up in those remote_hostio_pread
> calls? Reading the elf headers, parsing the symbol table, etc?
> Or maybe something else?
>
> 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?
Thanks,
Pedro Alves