[llvm] [llvm][Docs] Release note for LLDB optionally disabled regsets for RV64 (PR #123363)

[Alexey Merzlyakov via llvm-commits]

================
@@ -483,6 +483,8 @@ Changes to LLDB
   to be opened in the firewall (one for the `lldb-server` platform, one for gdbserver connections).
   In addition, due to this work, `lldb-server` now works on Windows in the server mode.
 
+* LLDB now supports optionally enabled/disabled register sets (particularly FPR) for RISC-V 64. The situation might take place for RISC-V builds having no FP-registers, like RV64IMAC or RV64IMACV. The change is applied to native debugging or core-file usage. EmulateInstruction is out of scope of the change, so its behavior remains the same using the maximum set of registers.
----------------
AlexeyMerzlyakov wrote:

Thank you for the review. Met review comments in https://github.com/llvm/llvm-project/pull/123363/commits/503c478245b2116470a7b2b8dad15d433c84291f.

Regarding sentence about emulation, I initially have some doubts when written it. However in both cases: unwinding mechanism or in single step prediction, code initially built for non-FPR architectures should not include addressing FP-registers, so this should not touch end-users.

The scenario when we run FPR-generated code e.g. on RV64IMAC, is out of correct usage scenario, I believe. The behavior of LLDB on this case might be unpredictable in other places: e.g. we are running RV64GC code on RV64IMACV, and the FP-registers in the code will have the same numbers as vector registers in H/W build. Thus FPR will be treated as VPR. So, this scenario initially better to be treated as incorrect and thus not mentioned.

And thus, I would like to agree, that is better to skip the last sentence, as it might cause a confusion.

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