[Lldb-commits] [lldb] [lldb] New expedited register specfication for unavailable regs (PR #193894)

[David Spickett via lldb-commits]

================
@@ -274,23 +295,31 @@ bool GDBRemoteRegisterContext::ReadRegisterBytes(const RegisterInfo *reg_info) {
           success = false;
         else {
           // Read the containing register if it hasn't already been read
-          if (!GetRegisterIsValid(prim_reg))
+          if (GetRegisterIsUnfetched(prim_reg))
             success = GetPrimordialRegister(prim_reg_info, gdb_comm);
----------------
DavidSpickett wrote:

If we define "read" as "get the value" then these two are the same:
* Got no bytes.
* Got some bytes.

If we're saying that "got no bytes" means unavailable, I don't see that treating "got some bytes" differently adds much for users.

Maybe for us we think it might, because we now think ok was it a network corruption, did the stub crash, is the register size out of sync etc etc, but by that point we're already looking into internals anyway. We can see this some versus no bytes by looking at the packet logs.

One way to create the "some bytes" would be if lldb thought that SVE was longer than it actually is. This would be a bug though, because we have a "proper" way (which is just as ugly but got here first :) ) to detect length that should have prevented this from happening.

Maybe you could have some sort of streaming queue register where you can read it over and over and it pulls from a queue. There is some research RISC-V thing with these. Even then, I'd be interested in the contents of the queue and how many slots were empty. So I'd make debug reads return the same size read each time, that of the maximum possible queue size.

Which is all to say: I am in favour of being more harsh in the error handling.

https://github.com/llvm/llvm-project/pull/193894