nitesh.jain added a comment.
In https://reviews.llvm.org/D24124#543823, @clayborg wrote:
> A few things about a the RegisterContext class in case it would change and
> thing that you are submitting here. The entire register context defines a
> buffer of bytes that can contain all register values. Each RegisterInfo
> contains the offset for the value of this register in this buffer. This
> buffer is said to have a specific byte order (big, little, etc). When a
> register is read, it should place its bytes into the RegisterContext's buffer
> of bytes and mark itself as being valid in the register context. Some
> platforms read multiple registers at a time (they don't have a "read one
> register value", they just have "read all GPR registers") and lets say you
> are reading one GPR, and this causes all GPR values to be read, then all
> bytes from all GPR values will be copied into the register context data
> buffer and all GPRs should be marked as valid. So to get a RegisterValue for
> a 32 bit register, we normally will just ask the RegisterInfo for the offset
> of the register, and then extract the bytes from the buffer using a
> DataExtractor object. If you have a 64 bit register whose value also contains
> a 32 bit pseudo register (like rax contains eax on x86), then you should have
> a RegisterInfo defined for "rax" that says its offset is N, and for a big
> endian system, you would say that the register offset for "eax" is N + 4.
> Extracting the value simply becomes extracting the bytes from the buffer
> without the need for any tricks. After reading all of this, do you still
> believe you have the right fix in here? It doesn't seem like you ever should
> need to use DataExtractor::CopyByteOrderedData???
The issue was in RegisterValue::GetUInt64 function returning incorrect value
for register of size 4/2/1 byte on 32 bit big endian system. We have modify it
to return value based on register size which will fix the register read/write
problem on 32 bit big endian system.
lldb-commits mailing list