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: Yao Qi <yao at codesourcery dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 18 Nov 2013 17:29:38 +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>
Hmm, do we really this all this memory range merging and stuff?
+ MEMADDR MEMADDR + LEN
+ |<------------------------------------------------->|
+ |<-- wo1 -->| |<-- wo2 -->|
+
+ |<-r1->| |<--r2-->| |<---r3---->|
+
+ -u-|-----c----|-----u----|-----c----|-----c----|--u--
+ 'u' stands for unchaced 'c' stands for cached.
+
+ |u1|-c1-| | u2 |c2| |--c3--| u3 |
+
+ Uncached ranges are u1, u2 and u3, and cached ranges are c1,
+ c2 and c3. */
I feels like the dcache code only needs to find the next
boundary, and read/write till that. That is, say, for a read,
the first dcache_xfer_memory would find the u1/c1 boundary,
then read [MEMADDR,u1/c1], and return. memory_xfer_partial
will then request another chunk, starting at u1/c1. That starts
at a cached range, so dcache would return c1. memory_xfer_partial
then requests more data, starting at the end of c1. That hits
a cached, non-readable range, so dcache returns error. Etc.
I think finding the next cached/uncached boundary address should
be simpler than getting vecs of ranges and merging them all,
and handling reads/writes separately. If the next boundary
spans multiple dcache lines, then you'd still read multiple
lines in one go.
--
Pedro Alves