Part of Firmware Reversing.

• Naive symbol-table address: 0x791580 (VA 0xf701f274)
• True prologue start: 0x7914d0 (VA 0xf701f1c4)
• Real, confirmed end: a clean, visible blr at 0x7919f4 — this function does NOT show the "no locally-visible blr" anomaly seen elsewhere on this wiki. Real total size: 0x528 (1,320) bytes, file range 0x7914d0-0x7919f8 (the next function's own prologue starts immediately at 0x7919f8, with no gap).
• Status: 🟡* Partially traced — real disassembly and call-target evidence exist for the whole function, but it is NOT a simple leaf helper (despite its name) and a full line-by-line transcription of all ~330 instructions wouldn't be proportionate; the real call targets below are the valuable part.
• Full mangled name: mv_convert_slot_nr__FPi (global function, int* argument)

Despite living in the maneuver-generator (mv_*) internals and taking a single int*, this function is a substantial, branchy routine (one backward loop, ~15 real calls, several bounds/validity checks). Only the very first and one later call actually do what the name suggests. Update, on re-checking: several of the "other subsystems" this section originally claimed (network sockets, file-output logging) were built on call-target names now confirmed wrong — see the corrected table and Net Read below. What survives re-verification: real ADAS message dispatch (CArr_AdasMain::parseMessage) and real route/ road-class-statistic math.

named symbol-table entries — see Firmware Reversing, "The load base") — corrected: 2 of these names turned out wrong

Target	What it suggests
setJunctionId__16CfcTypeNavDBInfoi (called twice — once near the top, once inside a conditional branch)	The one part that matches the function's own name: converts a raw slot number into a junction ID and stores it via CfcTypeNavDBInfo::setJunctionId(int)
IsValid__10EHTreeNodel	Wrong name — this call address is real (confirmed), but the content at it is a field-by-field OBJECT COMPARISON (operator==-shaped), not a validity check against a long. See the real, confirmed struct layout this call address anchors — plausibly still EHTreeNode-related by context, but not literally "IsValid"
parseMessage__13CArr_AdasMainRC9msgheader (called 3 times)	A previously-unknown real class, CArr_AdasMain — "Adas" strongly implies Advanced Driver Assistance System. Called repeatedly with a message header, i.e. this function is (partly) an ADAS message-parsing/dispatch loop, not pure maneuver math
writeProtocolHeader__19CfcNetMemoryChannel	Wrong name — this address ALSO lands inside the same confirmed accessor cluster linked above (a trivial single-field getter/setter, not a protocol-header writer)
close__21CfcIoFileOutputStream	Wrong name — re-checked this round: the real content is another string/constant selector dispatching on a small integer (cmpwi r29,0/1/2), not a file-close operation
__vd__20CfcNetAbstractSocketPv	Wrong name, checked — this address (0x76ea6c) is actually a real CONSTRUCTOR for the same object documented on the struct-layout page, zero-initializing several already-confirmed fields and calling a new real function, getData__21VpSimEventSetPositionPlN21PUlPb — not a socket destructor at all, but a genuinely valuable find in its own right
__vd__29CfcTypeNavMediaUpdateProgressPvUi	Wrong name, checked — this address (0xa41608-adjacent range, 0xa406b4) is pure embedded DATA (every word fails to decode, including 2 literal pointer-shaped values) — not a destructor, not even code. Consistent with it already being flagged lower-confidence (beyond the reliable <9MB window)
getOffroadDistanceFromRouteToDestination__25CfcTypeRoadClassStatistic	A real, directly nav-relevant function — this one recurs across several INDEPENDENT call sites on this wiki (mv_lefthand_traffic, registerBlocking's own neighbor, etc.), which is much stronger evidence than a single resolution; treated as reliable
setParameter__Q24edal17CSqlExecStatementlRC9CfcEntity	Possible SQL-statement parameter binding — already flagged lower-confidence (resolves past the confirmed-reliable <9MB window); given the pattern above, likely also wrong, not re-checked

Final tally for this page's original call-target list: 5 of 7 checked names confirmed wrong (IsValid, writeProtocolHeader, close, CfcNetAbstractSocket destructor, CfcTypeNavMediaUpdateProgress destructor) — only setJunctionId, parseMessage__13CArr_AdasMain, and getOffroadDistanceFromRouteToDestination (recurring across independent call sites) should be trusted from this page.

Several short, paired "undecodable" 4-byte words appear right after mtlr in a few of these call sequences (e.g. right before the 2nd and 3rd parseMessage calls) — the same <data>-not-a-real-instruction shape already documented on filterToggleSeg, not re-investigated here.

mv_convert_slot_nr is a real maneuver-generator entry point that, in addition to its namesake slot-to-junction-ID conversion, calls into the real CArr_AdasMain ADAS messaging class (parseMessage, recurring consistently across many independent call sites project-wide — this name is trusted) and touches real route/road-class-statistic math (getOffroadDistanceFromRouteToDestination, same reasoning). The "network-socket-backed IPC channel" and "file-output logging" claims from the original pass are retracted — both rested on names now confirmed wrong (writeProtocolHeader, close__21CfcIoFileOutputStream), and the remaining CfcNetMemoryChannel/CfcNetAbstractSocket entries project-wide trace back to the same unverified resolution method, so that whole narrative thread should be treated as unconfirmed rather than real until independently re-checked, not just this one page's copy of it.

Listed above; not individually traced beyond their names.