[PATCH v4 6/7] winedbg: Cache GDB qXfer command result for chunked fetching.

Jinoh Kang jinoh.kang.kr at gmail.com
Fri Nov 19 07:41:50 CST 2021


GDB does not retrieve the result of a qXfer command at once; instead, it
issues a series of requests to obtain the result one "chunk" at a time,
and concatenates those chunks internally.  Each request contains offset
and length variables that specify which portion of the result shall be
retrieved.

Today, Winedbg handles this by generating the entire result data each
time a request is received and slicing out the requested range for the
response.  This is not only inefficient due to repeated computation,
but also prone to race condition since the result may change between
successive chunk requests due to the dynamic nature of some commands
such as "libraries" and "threads."

Fix this by cacheing the result into a buffer at the first request, and
use the buffer to serve successive chunk requests.  The cache is
invalidated when the remote requests a different object, or the debugger
reaches the end of the result cache buffer.

Signed-off-by: Jinoh Kang <jinoh.kang.kr at gmail.com>
---

Notes:
    v3 -> v4: Synchronize to prior modified patches.

 programs/winedbg/gdbproxy.c | 31 +++++++++++++++++++++++--------
 1 file changed, 23 insertions(+), 8 deletions(-)

diff --git a/programs/winedbg/gdbproxy.c b/programs/winedbg/gdbproxy.c
index ace3c71492c..743bd95a5e7 100644
--- a/programs/winedbg/gdbproxy.c
+++ b/programs/winedbg/gdbproxy.c
@@ -2141,14 +2141,26 @@ static enum packet_return packet_query(struct gdb_context* gdbctx)
 
             TRACE("qXfer %s read %s %u,%u\n", debugstr_a(object_name), debugstr_a(annex), off, len);
 
-            reply_buffer_empty(&gdbctx->qxfer_buffer);
+            if (off > 0 &&
+                gdbctx->qxfer_buffer.len > 0 &&
+                gdbctx->qxfer_object_idx == i &&
+                strncmp(gdbctx->qxfer_object_annex, annex, QX_ANNEX_SIZE) == 0)
+            {
+                result = packet_send_buffer;
+                TRACE("qXfer read result = %d (cached)\n", result);
+            }
+            else
+            {
+                reply_buffer_empty(&gdbctx->qxfer_buffer);
 
-            gdbctx->qxfer_object_idx = i;
-            lstrcpynA(gdbctx->qxfer_object_annex, annex, QX_ANNEX_SIZE);
+                gdbctx->qxfer_object_idx = i;
+                lstrcpynA(gdbctx->qxfer_object_annex, annex, QX_ANNEX_SIZE);
 
-            result = (*qxfer_handlers[i].handler)(gdbctx);
-            TRACE("qXfer read result = %d\n", result);
+                result = (*qxfer_handlers[i].handler)(gdbctx);
+                TRACE("qXfer read result = %d\n", result);
+            }
 
+            more = FALSE;
             if ((result & ~packet_last_f) == packet_send_buffer)
             {
                 packet_reply_xfer(gdbctx,
@@ -2158,9 +2170,12 @@ static enum packet_return packet_query(struct gdb_context* gdbctx)
                 result = (result & packet_last_f) | packet_done;
             }
 
-            gdbctx->qxfer_object_idx = -1;
-            memset(gdbctx->qxfer_object_annex, 0, QX_ANNEX_SIZE);
-            reply_buffer_empty(&gdbctx->qxfer_buffer);
+            if (!more)
+            {
+                gdbctx->qxfer_object_idx = -1;
+                memset(gdbctx->qxfer_object_annex, 0, QX_ANNEX_SIZE);
+                reply_buffer_empty(&gdbctx->qxfer_buffer);
+            }
 
             return result;
         }
-- 
2.31.1




More information about the wine-devel mailing list