This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 2/2] Read memory in multiple lines in dcache_xfer_memory.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]