This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 2/2] Read memory in multiple lines in dcache_xfer_memory.
- From: Pedro Alves <palves at redhat dot com>
- To: Doug Evans <dje at google dot com>
- Cc: Yao Qi <yao at codesourcery dot com>, gdb-patches <gdb-patches at sourceware dot org>
- Date: Mon, 18 Nov 2013 16:58:33 +0000
- Subject: Re: [PATCH 2/2] Read memory in multiple lines in dcache_xfer_memory.
- Authentication-results: sourceware.org; auth=none
- References: <1382066466-2551-1-git-send-email-yao at codesourcery dot com> <1382066466-2551-3-git-send-email-yao at codesourcery dot com> <21093 dot 37082 dot 516044 dot 631275 at ruffy dot mtv dot corp dot google dot com> <5265CB5E dot 8020505 at codesourcery dot com> <CADPb22ROmqc3xh0v2TzRkZ4cqgZHwQjNHsOQ-BFQuNmE0YGcCg at mail dot gmail dot com>
On 10/25/2013 06:08 PM, Doug Evans wrote:
> OTOH, there's no point in having a 256 byte line size of the
> memory-read-packet-size is 64.
That's an excellent point. I think that we could also address that
in another way, without having the dcache code query the target
(or targets!) for maximum sizes -- currently, each cache line has a
fixed size, but instead, dcache could treat the line
size as the _maximum_ line size. That is, 'struct dcache_block' would
gain a new field that recorded much much data actually is stored
in the block. Then, when filling the block, dcache would use
target_xfer_partial instead of target_read/write, and if if the target
returns less than the block size, record how much it was read in the
block, and return to the dcache caller. Further partial transfers
would fill the rest of the dcache line (up until it was full). In
essence, dcache works at the target_xfer level, but has its own
loop that sort of "breaks" the partial transfer logic.
--
Pedro Alves