Re: [PATCH 0/2] Better handling of slow remote transfers

Pedro Alves
2015-08-12T13:58:55Z

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.

Thanks,
Pedro Alves