nitesh.jain added a comment. In https://reviews.llvm.org/D24603#548902, @clayborg wrote:
> So it seems like this can be fixed by doing a few things: > 1 - just set the RegisterInfo.offset to the actual offset in the buffer and > don't use the offset as the ptrace key used to grab the register > 2 - modify the RegisterInfo.kinds[eRegisterKindProcessPlugin] to be the > offset to you to use for ptrace > > There should be no need what so ever to do manual bit twiddling with src and > dst. The floating point register size can be dynamically changes . Hence following cases are possible when we read registers from ptrace in FPR_linux_mips buffer (In case of MIPS, ptrace always return value in 64 bit container irrespective of Arch). 1. Floating point register size is 32 (SR.FR = 0). a) In case of big endian system, the FPR_linux_mips.f0 will contains two floating point registers . The $f0 register will be store in upper 32 bit and $f1 register in lower 32 bit of FPR_linux_mips.f0. The FPR_linux_mips.f1 will contain don't care value and similarly for all other registers. Thus each even buffer will contain valid value and represent two registers. b) In case of liitle endian , the $f0 will be store in lower 32 bit and $f1 in upper 32bit of FPR_linux_mips.f0. The FPR_linux_mips.f1 will contain don't care value and similarly for all other registers. 2. Floating point register size is 64 (SR.FR = 1). In these case all buffer will have valid value. Hence we need bit twiddling with src and dst (in case of SR.FR = 0) so that each buffer will represent value for single register. https://reviews.llvm.org/D24603 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
