nitesh.jain added a comment.

In, @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

Reply via email to