1.5 KiB
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 doingReadMemory. - 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 inUEFNameSummaryProvider, where the underlying storage is an untyped block array).