NationalSecurityAgency/ghidra · error · ValueError

Invalid byte_order: {}

Error message

Invalid byte_order: {}

What it means

Raised by DefaultRegisterMapper.__init__ in the Ghidra LLDB agent when the byte_order argument is not one of 'big' or 'little'. The mapper needs a valid endianness to encode/decode register byte values; any other string (or a typo like 'BIG', 'LE', 'big-endian') is rejected at construction. ValueError signals an invalid configuration argument.

Source

Thrown at Ghidra/Debug/Debugger-agent-lldb/src/main/py/src/ghidralldb/arch.py:298

            f"Address {address} is not in process {proc.GetProcessID()}")


DEFAULT_MEMORY_MAPPER = DefaultMemoryMapper('ram')

memory_mappers: Dict[str, DefaultMemoryMapper] = {}


def compute_memory_mapper(lang: str) -> DefaultMemoryMapper:
    if not lang in memory_mappers:
        return DEFAULT_MEMORY_MAPPER
    return memory_mappers[lang]


class DefaultRegisterMapper(object):

    def __init__(self, byte_order: str) -> None:
        if not byte_order in ['big', 'little']:
            raise ValueError("Invalid byte_order: {}".format(byte_order))
        self.byte_order = byte_order

    def map_name(self, proc: lldb.SBProcess, name: str) -> str:
        return name

    def map_value(self, proc: lldb.SBProcess, name: str, value: bytes) -> RegVal:
        return RegVal(self.map_name(proc, name), value)

    def map_name_back(self, proc: lldb.SBProcess, name: str) -> str:
        return name

    def map_value_back(self, proc: lldb.SBProcess, name: str,
                       value: bytes) -> RegVal:
        if self.byte_order == 'little':
            value = bytes(reversed(value))
        return RegVal(self.map_name_back(proc, name), value)

View on GitHub (pinned to d5f144c24d)

Solutions

  1. Normalize the source byte-order value to exactly 'big' or 'little' before constructing the mapper.
  2. Add a translation step mapping LLDB's byte-order enum to {'big','little'}.
  3. Validate config-supplied endianness against {'big','little'} with a clear error before passing it in.
  4. Default to the target's detected endianness via a single normalized accessor.

Example fix

// before
mapper = DefaultRegisterMapper(raw_byte_order)
// after
_order = {'eByteOrderLittle': 'little', 'eByteOrderBig': 'big',
          'little_endian': 'little', 'big_endian': 'big'}.get(raw_byte_order)
if _order is None:
    raise ValueError(f"cannot normalize byte_order: {raw_byte_order}")
mapper = DefaultRegisterMapper(_order)
Defensive patterns

Strategy: validation

Validate before calling

_NORMAL = {'little', 'big'}
_order = raw_byte_order.lower() if isinstance(raw_byte_order, str) else None
if _order not in _NORMAL:
    raise ValueError(f"cannot normalize byte_order: {raw_byte_order}")
mapper = arch.DefaultRegisterMapper(_order)

Type guard

def is_valid_byte_order(v) -> bool:
    return isinstance(v, str) and v in {'big', 'little'}

Try / catch

try:
    mapper = arch.DefaultRegisterMapper(byte_order)
except ValueError:
    # invalid endianness; fall back to detected endianness
    mapper = arch.DefaultRegisterMapper(detected_endianness())

Prevention

When it happens

Trigger: Constructing DefaultRegisterMapper (or a subclass) with byte_order set from an unvalidated source — e.g. derived from LLDB's target byte order enum/string without normalization, a hardcoded value with a typo, or a config file value 'BE'/'LE'. Reached during compute_register_mapper / trace start.

Common situations: LLDB reports byte order in a form (e.g. 'little_endian', 'eByteOrderLittle') that was not normalized to 'little'; language config supplying abbreviated endianness; platform/target whose byte order string changed across LLDB versions.

Related errors


AI-assisted analysis of NationalSecurityAgency/ghidra@d5f144c24d (2026-08-14). Data as JSON: /api/errors/12987539e39fc91a. Report an issue: GitHub.