Firmware Fn getCurrentCarPosition

getCurrentCarPosition

Part of Firmware Reversing.

• File offset: 0x796fbc (VA 0xf7024cb0)
• Status: 🟢 Fully traced (108 bytes, 0x796fbc-0x797028 — a genuine LEAF function: no stwu/mflr at all, no stack frame, no calls. A completely different function's own clean, fresh stwu r1,-0x80(r1) prologue starts immediately after, no gap.)
• Full mangled name: getCurrentCarPosition__FR11DyCoCCPDataR16vehicle_location (global function, 2 reference arguments)
• UPDATE, confirmed via real Hex-Rays decompilation: 0xf7024cb0 is real, reachable code, but is not itself an independent function entry — IDA/Hex-Rays reports the real containing function starts 1,572 bytes earlier, at 0xf702468c (file offset 0x796998). The "genuine leaf, no stack frame at all" description above describes this address's own local behavior accurately, but the boundary framing needs correction: this is a call-reachable point inside a larger compiled function, the same pattern already documented on the EHTreeNode struct-layout page.
• Found via a real, confirmed call site on SetRouteObject (AdasRouteObject::SetRouteObject) — a reliable source, unlike the raw symbol-table address search (see Firmware Reversing for 2 cases this session where that search gave a wrong identification).

Disassembly

0x796fbc: lwz      r11, 0(r3)
0x796fc0: lwz      r0, 4(r11)
0x796fc4: cmpwi    r0, 0
0x796fc8: beq      0x796ff4
0x796fcc: mr       r11, r0
0x796fd0: lwz      r0, 0(r11)
0x796fd4: cmpwi    r0, 0
0x796fd8: beq      0x797020
0x796fdc: lwz      r11, 0(r11)          ; <- loop: walk the chain
0x796fe0: lwz      r0, 0(r11)
0x796fe4: cmpwi    r0, 0
0x796fe8: bne      0x796fdc
0x796fec: b        0x797020
0x796ff0: mr       r11, r9
0x796ff4: lwz      r9, 8(r11)
0x796ff8: lwz      r0, 4(r9)
0x796ffc: cmpw     r11, r0
0x797000: beq      0x796ff0
0x797004: lwz      r0, 4(r11)
0x797008: xor      r0, r0, r9
0x79700c: addic    r0, r0, -1
0x797010: subfe    r0, r0, r0           ; branchless: r0 = (r11.field4 == r9) ? -1 : 0
0x797014: andc     r9, r9, r0
0x797018: and      r0, r11, r0
0x79701c: or       r11, r0, r9          ; branchless select between r11 and r9
0x797020: stw      r11, 0(r3)
0x797024: li       r3, 0
0x797028: blr

Analysis

A genuine leaf function — no stack frame, no calls, just pointer chasing and branchless logic:

1. Reads *arg1 (the DyCoCCPData reference), then walks a real linked structure (0x796fd0-0x796fec): follow 0(r11) repeatedly until a NULL terminator, a classic chain-walk (same general shape as the EHTreeNode traversals seen on mv_convert_slot_nr/ SetRouteObject).
2. A branchless select (xor/addic/subfe/andc/and/or, 0x797004-0x79701c): compares a field of the found node against a secondary candidate (r9) and picks whichever one actually matches, without a conditional branch — a real, deliberate optimization (GCC commonly does this for short, performance- sensitive, branch-prediction-unfriendly selects).
3. Writes the resolved pointer into *arg2 (the output vehicle_location reference) and returns 0 (success).

Net read: resolves the real, current vehicle_location record by walking a chain of candidate position records (from DyCoCCPData, plausibly "Dynamic Coordinate/Car Position Data") and branchlessly picking the correct match, writing it to the caller's output reference. A small, self-contained, now fully understood utility — genuinely complete, nothing left unresolved.