tberghammer added a comment. As far as I know the gdb remote protocol says that the registers in the 'p' packet should be displayed in target byte order, but the protocol isn't too well specified (and in my opinion target byte order is a silly decision).
If we accept that the 'p' packet is in target byte order then I think using SetUInt works as intended in the current implementation and then we should fix the client side to interpret the register value as target byte order. I am also happy with the option of saying that we always send the register values as little endian but in that case my preferred way would be to use SetUInt without changing it's meaning and then doing the byte swapping (if needed) when we write the data into the response buffer (WriteRegisterValueInHexFixedWidth). The reason behind it is that if we want to use the ReadRegister call in lldb-server (e.g. software single stepping) then I would expect it to return the data in target byte order and this change would break this assumption. Additional info is that the current implementation works well if the client and the server use the same byte order. If we fix the communication to be in little endian then we will still have to fix the server (GDBRemoteRegisterContext::PrivateSetRegisterValue) to handle the case when lldb runs on a big endian machine. Repository: rL LLVM http://reviews.llvm.org/D14633 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
