[Lldb-commits] [PATCH] Opcode endianness proof-of-concept

[Ed Maste]

Thanks for looking Greg,

On 8 October 2013 16:04, Greg Clayton <gclayton at apple.com> wrote:
>
> A few things:
>
> - all opcode constructors that take uint8/16/32/64 should set the byte order to the host byte order (lldb::endian::InlHostByteOrder())

The issue though is that while the storage (in the m_data union) is of
course in host order, the opcode it represents needs to be returned in
target byte order when passed as ordered bytes (to the disassembler,
for example).  My thought was I'd use eByteOrderInvalid to indicate
that the byte order is unknown.  I default to assuming
InlHostByteOrder() on extraction if the byte order isn't explicitly
set, to maintain the current behaviour.

In e.g. InstructionLLVMC::Decode() I'd pass through the target's byte
order when creating an opcode to pass to the disassembler -- e.g.

case 4:
    m_opcode.SetOpcode32 (data.GetU32 (&data_offset));
    m_opcode.SetByteOrder (data.GetByteOrder());
    got_op = true;
    break;

I could have the SetOpcode* functions take a byte order parameter as
well, I guess.

> - The constructor that takes bytes + size should also take a byte order and we should mixup all places that use this constructor to specify a correct byte order

We only use that constructor for variable-sized instructions as far as
I can tell (e.g. x86), where they're implicitly just an ordered set of
bytes, and we never extract them through GetOpcode8/16/32/64 today.

Of course, another approach is to do away with the union and
conversion to/from host order, and just maintain the opcode data
always in target order.  I originally started down that path but it's
a more extensive change, so wanted to propose this for discussion
first.