
<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hello people,<div><br></div><div>I'm using lldb on an Intel Mac (little endian), and working on a stub for a program that emulates a PowerPC (big endian).</div><div><br></div><div>The GDB protocol says this about commands for reading registers:</div><div><br></div><div></div><blockquote type="cite"><div>`XX...'<br>Each byte of register data is described by two hex digits. The bytes with the register are <b>transmitted in target byte order</b>. The size of each register and their position within the `g' packet are determined by the GDB internal macros REGISTER_RAW_SIZE and REGISTER_NAME macros. The specification of several standard g packets is specified below.</div></blockquote><div><br></div><div>So I'm doing just that, replying in big endian. However, RegisterContextLLDB::ReadGPRValue isn't endian-aware: GetRegisterContext()->ReadRegister (where RegisterContext is a GDBRemoteRegisterContext) reads my big endian response and writes it one byte at a time in the register values buffer, effectively swapping it.</div><div><br></div><div>From my analysis, GDBRemoteRegisterContext::ReadRegister could do the swapping transparently, but GetRegisterSet (among others?) would still return swapped values; otherwise, using the register metadata, it should be possible to do the swapping when the values are read.</div><div><br></div><div>How hard would it be to fix lldb? Would I be better off doing a quick hack in my own stub to throw little endian values at lldb in the short term?</div><div><br></div><div>Félix</div></body></html>