Part of Firmware Reversing.

• Naive symbol-table address: 0x88a840 (VA 0xf7118534)
• True prologue start: 0x88a660 (VA 0xf7118354) — found by scanning backward for the nearest real stwu/mflr prologue, independently confirmed valid (capstone decodes it as a genuine stwu instruction, not a misaligned read)
• Status: 🟡 Partially traced — real logic confirmed, but the function's own return mechanism has a genuine, honestly-flagged anomaly (see below), so it isn't marked 🟢 yet
• Full mangled name: getIndexOfVid__9RoutePathPUlUlQ29RoutePath27ROUTE_PATH_SEARCH_DIRECTIONUiUiUiUi

Directly relevant: "Vid" is this project's own vnodeID terminology.

0x88a660: stwu     r1, -0xe0(r1)
0x88a664: mflr     r0
0x88a668: stmw     r29, 0xd4(r1)
0x88a66c: stw      r0, 0xe4(r1)
0x88a670: cmpwi    r4, 0
0x88a674: mr       r31, r3
0x88a678: mfcr     r29
0x88a67c: beq      0x88a698
0x88a680: lis      r9, -0x8a7
0x88a684: addi     r0, r9, 0x4b34
0x88a688: addi     r3, r31, 8
0x88a68c: mtlr     r0
0x88a690: stw      r3, 0(r31)
0x88a694: blrl                              ; virtual "constructor" call
0x88a698: lwz      r11, 0(r31)
0x88a69c: lis      r9, -0x86e
0x88a6a0: addi     r30, r9, -0x3d8          ; a vtable-ish pointer
0x88a6a4: stw      r30, 0(r11)
0x88a6a8: mtcrf    0x80, r29
0x88a6ac: bne      0x88a6f0
0x88a6b0: lis      r9, -0xb5
0x88a6b4: addi     r0, r9, -0x3a38
0x88a6b8: addi     r29, r1, 0x10
0x88a6bc: mtlr     r0
0x88a6c0: mr       r3, r29
0x88a6c4: mr       r4, r30
0x88a6c8: li       r5, 0xa8                 ; size = 0xa8
0x88a6cc: crclr    cr1eq
0x88a6d0: blrl                              ; another virtual call
0x88a6d4: lwz      r11, 0(r31)
0x88a6d8: lhz      r9, 8(r30)
0x88a6dc: addi     r0, r11, -8
0x88a6e0: stw      r29, 0(r11)
0x88a6e4: subf     r0, r0, r31
0x88a6e8: add      r9, r9, r0
0x88a6ec: sth      r9, 0x18(r1)
0x88a6f0: lis      r9, -0x86e
0x88a6f4: addi     r9, r9, -0x3f8
0x88a6f8: stw      r9, 4(r31)
0x88a6fc: mr       r3, r31
0x88a700: lwz      r0, 0xe4(r1)
0x88a704: mtlr     r0
0x88a708: lmw      r29, 0xd4(r1)
0x88a70c: addi     r1, r1, 0xe0
0x88a710: <data>    00670039   ; not a valid instruction -- see anomaly note below

Tests arg2 (r4) against zero, conditionally calls a virtual "constructor" (blrl at 0x88a694, matching the same mtlr+blrl pattern seen in every other traced function on this wiki), writes a vtable-ish pointer (0x88a6a0/0x88a6a4), then — on one branch — allocates/constructs a 0xa8-byte object (li r5,0xa8 immediately before another blrl, the same size-argument-before-allocator-call shape confirmed in ResolveUnsetNodeID), then performs a pointer-arithmetic copy (subf/add computing an offset from r31, similar in shape to getId's own field-copy step). This is real, coherent, purposeful code consistent with a "resolve/construct an index/VID lookup object" role matching the function's own name.

The function pops its stack frame (addi r1,r1,0xe0 at 0x88a70c) but the word immediately after does not decode as blr or any other valid instruction (raw bytes 00 67 00 39, primary opcode 0, undefined). This is the SAME general "no local blr visible" shape seen in getNodeVidArmMP0 — but there, a clear backward branch explained it (a real loop). Here, no such branch was found feeding this exact point, and immediately after a long stretch of clearly-non-code interstitial data, an almost byte-identical SECOND copy of this same function body begins around 0x88a9a0 (same prologue shape, same li r5,0xNN-before-blrl pattern, different embedded constants) — consistent with this symbol representing multiple real C++ overloads (the mangled name's trailing ...UiUiUiUi suggests several enum/uint argument combinations, each compiled to its own near-duplicate function body). Whether the "missing blr" is a genuine shared-epilogue tail-branch this trace didn't follow, or something else, is not resolved — recorded honestly as an open question rather than assumed away.

Checked (cross-referencing every lis/addi pair in the function's confirmed range against the real symbol catalog, the same technique used elsewhere on this wiki): zero named call targets found — both blrl calls here go through a computed vtable pointer with no direct lis/addi reference to a named function, i.e. these are genuine virtual calls whose real target can't be resolved statically this way.