In previous versions of AVaRICE, a complete processor status was sent
after every instruction, apparently to prevent GDB from asking for the
status itself. In GDB 7.6, this is not required: GDB only asks for the
status after a code line (not instruction) was finished. By removing the
frequent status read in AVaRICE, debugging can be sped up.
>From 41a4e8549cbff0632d13d3a2e862fd4f57604bd2 Mon Sep 17 00:00:00 2001
From: Martin Hofmann <martin.hofm...@studium.uni-erlangen.de>
Date: Fri, 14 Mar 2014 15:48:19 +0100
Subject: [PATCH] Remove sending status after every single step

In previous versions of AVaRICE, a complete processor status was sent
after every instruction, apparently to prevent GDB from asking for the
status itself. In GDB 7.6, this is not required: GDB only asks for the
status after a code line (not instruction) was finished. By removing the
frequent status read in AVaRICE, debugging can be sped up.
---
 avarice/src/remote.cc | 44 +++++++++++++-------------------------------
 1 file changed, 13 insertions(+), 31 deletions(-)

diff --git a/avarice/src/remote.cc b/avarice/src/remote.cc
index e5d3f12..a3884ee 100644
--- a/avarice/src/remote.cc
+++ b/avarice/src/remote.cc
@@ -296,47 +296,29 @@ void gdbOut(const char *fmt, ...)
 
     Reply with a packet of the form:
 
-      "Tss20:rr;21:llhh;22:aabbccdd;"
+      "Tss;22:aabbccdd;"
 
     where (all values in hex):
       ss       = signal number (usually SIGTRAP)
-      rr       = SREG value
-      llhh     = SPL:SPH  (stack pointer)
       aabbccdd = PC (program counter)
 
-    This actually saves having to read the 32 general registers when stepping
-    over code since gdb won't send a 'g' packet until the PC it is hunting for
-    is found.  */
+    Contrary to previous versions, we do not send the stack pointer and the
+    status registers every time we receive a break event during single stepping.
 
+    This way, GDB 7.6 requests a full 32 byte status after every completed code
+    line. The time needed to read the complete status is only around 50 ms
+    longer than reading the small status. Therefore, it seems reasonable to
+    not read the status every time.
+*/
 static void reportStatusExtended(int sigval)
 {
-    uchar *jtagBuffer;
     unsigned int pc = theJtagICE->getProgramCounter();
 
-    // Read in SPL SPH SREG
-    jtagBuffer = theJtagICE->jtagRead(theJtagICE->statusAreaAddress(), 0x03);
-
-    if (jtagBuffer)
-    {
-        // We have SPL SPH SREG and need SREG SPL SPH
-
-        snprintf (remcomOutBuffer, sizeof(remcomOutBuffer),
-                  "T%02x" "20:%02x;" "21:%02x%02x;" "22:%02x%02x%02x%02x;",
-                  sigval & 0xff,
-                  jtagBuffer[2], // SREG
-                  jtagBuffer[0], // SPL
-                  jtagBuffer[1], // SPH
-                  pc & 0xff, (pc >> 8) & 0xff,
-                  (pc >> 16) & 0xff, (pc >> 24) & 0xff);
-
-        delete [] jtagBuffer;
-        jtagBuffer = 0;
-    }
-    else
-    {
-        error(1);
-        return;
-    }
+    snprintf(remcomOutBuffer, sizeof(remcomOutBuffer),
+             "T%02x" "22:%02x%02x%02x%02x;",
+             sigval & 0xff,
+             pc & 0xff, (pc >> 8) & 0xff,
+             (pc >> 16) & 0xff, (pc >> 24) & 0xff);
 }
 
 /** Fill 'remcomOutBuffer' with a status report for signal 'sigval' **/
-- 
1.9.0

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
avarice-user mailing list
avarice-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avarice-user

Reply via email to