Files
jbashrc/claude/integration-memory/feedback_lldb_formatter_style.md
2026-04-20 20:52:50 -04:00

1.5 KiB

name, description, type, originSessionId
name description type originSessionId
LLDB data formatter style — let lldb do the math In tools/UEDataFormatter.py and similar lldb formatter code, use typed SBValues so lldb handles alignment/pointer-size/endianness, rather than doing raw byte math in Python. feedback 783fd7be-2cf8-4075-a708-2909c6cf000b

In tools/UEDataFormatter.py (and any other lldb data formatter code in this project): use typed SBValues to let lldb compute offsets, alignments, pointer sizes, and endianness. Do not do raw pointer arithmetic, byte-offset math, or architecture-assumption math in Python.

Why: Manual math assumes things about the target (pointer size, struct layout, endianness) that lldb already knows from debug info. Letting lldb do it via typed SBValue APIs — GetChildMemberWithName, Dereference, CreateValueFromAddress(addr, type), GetArrayType, GetTemplateArgumentType, etc. — is portable, robust, and avoids subtle bugs when the target architecture changes.

How to apply: When writing or editing a summary/synth provider:

  • Prefer GetChildMemberWithName('X') over computing a field's offset and doing ReadMemory.
  • Prefer CreateValueFromAddress(addr, sometype) over raw reads followed by manual decoding.
  • Use GetArrayType(N) / GetTemplateArgumentType(i) to derive element types rather than hardcoding sizes.
  • Only drop to raw process.ReadMemory / pointer math when no typed path exists (e.g., walking the GNameBlocks table in UEFNameSummaryProvider, where the underlying storage is an untyped block array).