omjavaid added a comment. In D82863#2341628 <https://reviews.llvm.org/D82863#2341628>, @labath wrote:
> I'm afraid I don't understand what you mean. Could you try to be more > specific? > > It's true that currently lldb client uses the register offsets provided by > the server (if they are present), and this is a divergence from pure > gdb-remote. Were it not for variable-sized registers, I might even say that > it is a good one. What the current patch does though is add another exception > to the rule. This exception means that the offset provided by the server may > not actually be the definitive value -- the client may choose to override it > based on some built-in knowledge (and then assume the server has the same > knowledge). > > My proposal is to avoid this exception, and make it such that the > server-provided offset is always definitive. And in cases where a definitive > answer cannot be provided, the server will just not send the offset over. I agree with your thoughts about not sending offset, infact as far as AArch64 is concerned if we skip sending offset for SVE registers we can construct offset filed anyway by running UpdateARM64SVERegistersInfos in DynamicRegisterInfo::Finalize function. In principle offsets are always definitive and sending explicit Offset is actually redundant information we actually dont need it as it can be calculated based on register size in the increasing order of register numbers. If we know variable sized SVE registers are always going to come after VG register we can always know the correct location of these registers in g packet. We also know FFR is the last SVE register and any data after FFR will correspond to any new registers that may be added after SVE. What we essentially need here is to sync register numbers and register sizes between client and server. The offset field in register info structure must be populated corrently on both client and server side for read/write of register data from its correct location in register data heap. In addition to that for variable sized registers we need a mechanism to update the size and offset fields of variable register and also the register coming after those registers. But this is easier said than done though, first, for all architectures we need to see how offset field in their RegisterInfo structs is being formulated. If it is being populated based on the same formula of increasing order of register numbers then we can write a simple patch to skip offset field but if its not that way and random offsets are being used then we ll have to go on and make the changes in Register Infos structs of all those individual architectures making this change. Secondly, this offset field also determines the location of value_regs without the offset field being explicitly sent across we cannot exactly be sure about the location of pseudo registers in g/G packet data. GDB's XML register description format does not have a provision for pseudo registers rather it has user defined register types what it calls composite types where a register can be vector, union or struct of various custom fields. Finally, how about I post an update of this patch where lldb client side will ignore offset it receives for SVE register and incrementally places variable sized SVE registers after VG register. For any future registers we can choose an to put them before SVE registers or add a mechanism to update their offset if they are placed after SVE. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D82863/new/ https://reviews.llvm.org/D82863 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
