labath added a comment. Where does the option which I proposed fit in? It sounds like it would be something like 1a), where we don't actually modify the "invalidate" numbers stored within lldb-server, but we just do the conversion at the protocol level. That way the "invalidate" numbers keep their meaning as "lldb" register numbers in lldb-server, just like they used to. They also keep referring to "lldb" register numbers on the client side, because the client puts the register "index" into the "lldb" field. The only inconsistency is that the "lldb" register numbers assigned to a specific register will be different on the client and server side. However:
- this is not different from what happens in your patch, because you put the "server lldb" number into the "process plugin" field on the client - it's not something we should actually rely on if we want to be able to communicate with non-matching server stubs It seems to me like this solution has the same downsides as the current patch, while having the upside of not requiring protocol changes. That means it can be revisited if we find it to be a problem, while a protocol change is more permanent. That's why I'd like to get a good understanding of why it won't work (or be ugly) if we're not going to do it, and so far I haven't gotten that. (BTW, if other aarch64 targets (which ones?) are reporting debug registers in their register lists, I don't think it would be unreasonable to do the same on linux) CHANGES SINCE LAST ACTION https://reviews.llvm.org/D77043/new/ https://reviews.llvm.org/D77043 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
