================
@@ -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
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
