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

[Jason Molenda via lldb-commits]

jasonmolenda wrote:

Oh interesting point about how writing to s0/d0 impacts the unspecified bits of v0.  But if we think of intel with rax/eax/ah/al, if I do `reg write ah 5`, I don't know if I meant for the other 48 bits to be overwritten when I did that.  
(this is hard to write a test for because it requires that rax's value wasn't included in the expedited registers from the gdb stub -- it's only registers outside the GPRs where we can see this problem)

And in the case of this shell test with `fip` aka `[fiseg, fioff]` register, I don't know what it would mean for `fiseg` if I change the value of `fioff` -- if it's correct to preserve the value that was in `fiseg` or if it should be reset to the register context's uninitialized value (0's historically).

If i'm going to make an error, I think I would rather read the full `fip` register, modify the 32-bits the user asked to modify, and send the new 64-bit value back to the gdb stub, even if it's not the behavior an assembly language on the cpu would have had setting half of the register.  Otherwise it seems like we need to know too much about the behavior of the registers.

If we look at the behavior with an expedited register, like

```
< 870> read packet: $T05thread:684d3b;threads:684d3b;thread-pcs:100000328;00:0100000000000000;01:28f8df6f01000000;[...]

(lldb) reg read x1
      x1 = 0x000000016fdff828
(lldb) reg write w1 5
 <  38> send packet: $P1=0500000001000000;thread:684d3b;#87
 <   6> read packet: $OK#00
```

only the low 32 bits are overwritten by my command, and the high 32 are maintained as-is.  It's only when we have non-expedited values that we're seeing this other behavior with uninitialized data being sent back.

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