[Lldb-commits] [PATCH] D11187: Add jThreadsInfo support to lldb-server

[Jason Molenda]

jasonmolenda added a subscriber: jasonmolenda.

================
Comment at: docs/lldb-gdb-remote.txt:1555-1575
@@ +1554,23 @@
+        "registers": {
+          "0":"8000000000000000",
+          "1":"0000000000000000",
+          "2":"20fabf5fff7f0000",
+          "3":"e8f8bf5fff7f0000",
+          "4":"0100000000000000",
+          "5":"d8f8bf5fff7f0000",
+          "6":"b0f8bf5fff7f0000",
+          "7":"20f4bf5fff7f0000",
+          "8":"8000000000000000",
+          "9":"61a8db78a61500db",
+          "10":"3200000000000000",
+          "11":"4602000000000000",
+          "12":"0000000000000000",
+          "13":"0000000000000000",
+          "14":"0000000000000000",
+          "15":"0000000000000000",
+          "16":"960b000001000000",
+          "17":"0202000000000000",
+          "18":"2b00000000000000",
+          "19":"0000000000000000",
+          "20":"0000000000000000"
+        },
----------------
tberghammer wrote:
> I would prefer to use hex numbers to be consistent with the stop reply packet but that change is out of scope for this change. The missing support for hex isn't an issue here because of the quotes.
I agree with Tamas, the number-base assumptions in gdb-remote numbers are a nightmare; at this point even decimal can be misconstrued as hex.  I'd rather we just make it explicitly hex -- so instead of "14":, "0xe":.

I'm not a huge fan of sending back the registers as a series of bytes in target-native-endian order like this,

+          "5":"d8f8bf5fff7f0000",

I'd push for sending this back as a native JSON number object, so  "0x5":140734799804632 but this would cause problems if we try to transfer a 16-byte (or larger) vector register value - lldb's JSON parser is only designed to handle 64-bit integer values, as are most others I would expect - so maybe we have to live with this.  I'd argue for transposing to big-endian order but when we send the expedited memory contents we need to send those in target native endian order.

tl;dr: At least let's make the register numbers base 16 and prefixed with "0x".


http://reviews.llvm.org/D11187