Firmware Fn EHTreeNode struct layout

A real, confirmed struct layout — the object constructed/compared/accessed around 0x76ea6c-0x76ed68

Part of Firmware Reversing.

• File offset: core accessor/comparison cluster 0x76ec40-0x76ed68 (VA 0xf6ffc934-0xf6ffca5c, 568 bytes); a real constructor for the same object sits a little earlier at 0x76ea6c (see below) — not claimed to be perfectly contiguous with the cluster, just the same real class
• Status: 🟢 Fully traced — an unusually clean case: ~20 real, tiny, unambiguous leaf functions back-to-back, each either a comparison or a single-field getter/setter, no branches except the comparison function's own early-outs, no calls, no stack frames needed anywhere in this whole range.
• Naming caveat: the call site this was found from (a real, reloc-confirmed call in mv_convert_slot_nr) carried the broader-catalog-sourced name IsValid__10EHTreeNodel (EHTreeNode::IsValid(long)). The real content doesn't match that name: this function compares two FULL OBJECTS field-by-field (*r3 against *r4), not one object against a long — consistent with an operator==/equality-comparison method, not a validity check. Given this session's already-established pattern of bad names from the broader catalog (see Firmware Reversing), the class/method name is NOT trusted here — only the real call address and the real content are. The class is very plausibly still EHTreeNode or a close relative (the call site's own context, inside mv_convert_slot_nr, was already dealing with EHTreeNode objects) — a reasonable inference, not an independent confirmation.
• UPDATE: EHTreeNode is now independently confirmed to be a real class name — found via the whole-file lis/addi reloc-confirmed name catalog (see Firmware Reloc-Confirmed Names): a real constructor, __10EHTreeNodeUlUlP4vsegL (EHTreeNode::EHTreeNode(unsigned long, unsigned long, vseg*, long)), and a real method, GetFirstSegment__10EHTreeNode (EHTreeNode::GetFirstSegment()). This doesn't yet prove THIS specific accessor cluster/constructor pair is that exact class rather than a close relative, but it does confirm the class genuinely exists with this exact name — no longer just a contextual inference. Also worth clarifying: seeing a real sibling class EHDatagramGraph (SetSlope, IsLeftHand — real road-geometry/terrain methods) in the same catalog makes it clear this "EH" prefix means Electronic Horizon (the ADAS road-ahead-prediction subsystem), not "exception handling" — an unrelated, unfortunate naming coincidence with this wiki's own extensive "EH"/exception-handling (.frame_info) discussion elsewhere. Don't conflate the two.

The real, confirmed field layout

A real equality-comparison function (0x76ec40-0x76ec9c) checks 5 fields in sequence, early-exiting false on the first mismatch — and every one of those same 5 offsets ALSO has its own dedicated, individually-confirmed getter/setter pair immediately following, which cross-validates both the offsets and the field sizes:

Offset	Size	Type	Confirmed by
0x00	4 bytes	word	Compared in equality check; a FULL byte-by-byte getter/setter quartet also exists for bytes 0x00-0x03 individually (see below)
0x01	1 byte	byte	Individual getter (lbz r3,1(r3)) / setter (stb r4,1(r3))
0x02	1 byte	byte	Individual getter/setter
0x03	1 byte	byte	Individual getter/setter
0x04	1 byte	byte	Compared in equality check; own getter/setter
0x08	4 bytes	word	Compared; own getter/setter
0x0c	4 bytes	word	Compared (the LAST field checked — comparison returns the XOR-based 0/1 result of this one); own getter/setter
0x10	8 bytes	double (IEEE754)	Compared via fcmpu (real floating-point compare); own getter (lfd)/setter (stfd)
0x18	4 bytes	word	Own getter/setter (not part of the equality check)
0x1c	4 bytes	word	Own getter/setter
0x20	—	(embedded object/array, not itself loaded)	A dedicated accessor exists that returns this+0x20 as a POINTER (addi r3,r3,0x20; blr) rather than loading a value — consistent with an embedded sub-object or inline array starting here, continuing at least to offset 0x34 (a 20-byte gap)
0x34	1 byte	byte	Own getter/setter
0x38	4 bytes	word	Own getter/setter

Every accessor is a true leaf (no stack frame, 1-2 instructions, ends in a bare blr) — about as unambiguous as real-world compiled C++ gets to read.

A real constructor, found the same way, confirms and extends this layout

A 2nd broader-catalog name built on the same call address (__vd__20CfcNetAbstractSocketPv, claimed on mv_convert_slot_nr) resolves to 0x76ea6c, just before this cluster — also wrong (it's clearly not a socket destructor), but again worth reading rather than discarding: it's a real constructor for this same object. Zero-initializes fields at 0x1c, 0x34, 0x38 (all already confirmed above) and 0x08/0x0c (also already confirmed), computes this+0x20 (the same embedded sub-object pointer already confirmed), stores a real computed function-pointer value into THAT sub-object's own +4 (absolute +0x24) — a real vtable-pointer store, confirming the +0x20 sub-object is itself a genuine C++ object, not a plain buffer — and calls a new real function, getData__21VpSimEventSetPositionPlN21PUlPb, passing the sub-object as a parameter. "VpSimEventSetPosition" (vehicle- position simulation, "set position" event) is a real, previously- uncatalogued class name, and ties this whole struct back to the vehicle-position-simulation infrastructure also seen via simATASwitch/VpSimEvent elsewhere in this ADAS-adjacent code.

Net read

A real, now-confirmed in-memory layout for whatever class this is (plausibly EHTreeNode, inferred from context, not independently named): a leading 5-byte region (one word, 3 individually-addressable bytes, one more byte) that's part of this object's identity/equality, a double at 0x10 (likely a real-world coordinate or distance value, given this is in route/map-tree territory), 2 more words at 0x08/0x0c that also factor into equality, 2 further words at 0x18/0x1c outside the equality check, an embedded sub-object or array starting at 0x20, and 2 more fields at 0x34/0x38. A genuinely rare, high-confidence piece of real structural ground truth for this project's own EHTreeNode/route-tree work, independent of whatever the method itself should really be called.