Firmware Fn getSegProperty

getSegProperty — RoutePath::getSegProperty

Part of Firmware Reversing.

• Naive symbol-table address: 0x7f6bac (VA 0xf70848a0)
• True prologue start: 0x7f6594 (VA 0xf7084288)
• Status: 🟡* Partially traced — real, confirmed end at 0x7f6f30 (addi r1,r1,0x240 matching this function's own prologue frame size exactly, then a clean blr, then a genuinely DIFFERENT function's own fresh stwu r1,-0x180(r1) prologue starts immediately at 0x7f6f34). Real, confirmed size: 0x99c (2,460) bytes — a correction: an earlier pass on this page mistakenly also cited a 2nd "return point" at 0x7f7378 as belonging to this function; that address is likewise immediately followed by yet another different function's own fresh prologue (stwu r1,-0x1b0(r1)), so both "extra" bytes and any call targets found past 0x7f6f30 have been removed below — a full line-by-line transcription of the confirmed 2,460 bytes would still be excessive, so only the structural findings are documented, not every instruction
• Full mangled name: getSegProperty__9RoutePathUiR12_SegProperty

Confirmed structure

Real stwu r1,-0x240(r1) prologue (a 576-byte stack frame — by far the largest of any function traced on this wiki, consistent with real, substantial local work) saving r14-r31. Early body:

0x7f6594: stwu     r1, -0x240(r1)
0x7f6598: mflr     r0
0x7f659c: stw      r14, 0x1f8(r1)
...                                          ; r14-r31 saved, standard
0x7f65e4: stw      r0, 0x244(r1)
0x7f65e8: stw      r4, 0x1e4(r1)             ; save arg2
0x7f65ec: lis      r9, -0x91c
0x7f65f0: addi     r31, r9, -0x4ec8
0x7f65f4: stw      r3, 0x1e0(r1)             ; save arg1 (this)
0x7f65f8: lis      r4, -0x874
0x7f65fc: mtlr     r31
0x7f6600: addi     r4, r4, 0x5d14
0x7f6604: addi     r3, r1, 0x10
0x7f6608: mr       r24, r5
0x7f660c: mr       r21, r6
0x7f6610: lis      r30, -0x86d
0x7f6614: blrl                              ; virtual call #1 (constructor-shaped)
0x7f6618: lis      r4, -0x874
0x7f661c: mtlr     r31
0x7f6620: addi     r4, r4, 0x5d10
0x7f6624: addi     r3, r1, 0x20
0x7f6628: li       r8, 0
0x7f662c: stw      r8, 0x1e8(r1)             ; loop counter init
0x7f6630: blrl                              ; virtual call #2 (2nd constructor)

From there the function does REAL, substantial iteration: 0x1e8(r1) is used as a loop counter, incremented (addi r8,r8,1 around 0x7f689c) and compared against the saved arg2 (0x1e4(r1)) — a genuine for (i = 0; i < arg2; i++) shape. Inside the loop: multiple more virtual calls, a real linked-list/array traversal (lwz r9,0xc(r9) / srwi ...,2 — dividing a byte count by 4, a classic "count of 4-byte elements" idiom), and — most notably — several branchless boolean- negation idioms (nor/addic ...,-1/subfe sequences, e.g. around 0x7f6a48-0x7f6a84 and 0x7f6b10-0x7f6b20) used repeatedly to test computed flags before conditionally constructing more sub-objects on the stack (addi r29,r1,0xf0 etc, each followed by its own mtlr+blrl).

Analysis

This reads as a genuine segment-property enumerator: given a RoutePath and some count/index range (arg2), it loops, and for each iteration constructs one or more temporary property/result objects via virtual calls, testing several boolean conditions along the way (possibly per-property availability flags) before populating the output _SegProperty reference. This is consistent with the function's own name and is real, substantial, purposeful code — but tracing the EXACT meaning of each branch and sub-object would need the same kind of deep, dedicated pass the 4 fully-traced functions on this wiki got, and wasn't done here given the size.

Callees

Resolved by cross-referencing every lis/addi pair in the function's confirmed 0x99c-byte range (and ONLY that range — see the status note above about discarding call targets from the 2 neighboring functions a wider scan initially, mistakenly, attributed here too) against the real symbol catalog (the same technique used throughout the ADAS subsystem pages):

Target	What it suggests
getCertainty_total__23CfcTypePossibleLocation	Same map-matching confidence accessor seen on addSegmentData
getDbPartitions__22CfcTypeMapPOIPartition (2 call sites)	Same POI-partition query seen on addSegmentData
__nw__35CfcAspectGuidanceStatusChangedEventUi (2 call sites)	Same guidance-status-changed event seen on addSegmentData — getSegProperty fires this too
__vd__30CfcManeuverChangedListenerStubPvUi	Destructor of a real CfcManeuverChangedListenerStub — directly ties this segment-property enumerator to maneuver-change notification
useCostOfTrafficInformationArray__30CfcRoadwayBlockingManagerProxyiPt17CfcUtilFixedArray1ZiQ234CfcTypeRoadwayBlockingCostModifier28R	A real, previously-uncatalogued function — applies a traffic-information cost array via a RoadwayBlockingManagerProxy, i.e. segment properties here include live traffic-blocking cost adjustments
proc_mot_err__Fi (2 call sites)	A real, global "process MOST error" function — segment-property resolution can hit real MOST-bus error handling
getLastSegID__22CfcTypeStreetListEntry	Real accessor on a CfcTypeStreetListEntry
_$_28CfcPhonemeDataRetrieverProxy (destructor, 2 call sites)	Real CfcPhonemeDataRetrieverProxy — ties segment properties to phoneme/TTS (pronunciation) data retrieval
setJunctionId__16CfcTypeNavDBInfoi	Same shared primitive seen throughout the mv_*/ADAS functions
compose__9CfcString	Real string-composition call — builds a formatted string as part of a property result
getDbVersion	Real database-version accessor

Several __tf* entries also resolved (CfcAlternativeAvailableListenerProxy, CArrMsgHandler, CfcTypeRoadClassStatisticSummary) — these are real C++ type-descriptor (RTTI) symbols, not functions, but confirm 3 more real class names touched by this function.

Net read

getSegProperty is not a narrow accessor — it's a real aggregator that pulls together map-matching certainty, POI-partition data, live traffic-blocking costs, maneuver-change and guidance-status notifications, phoneme/TTS data, and street-list segment IDs into the caller's _SegProperty output, with real MOST-bus error handling (proc_mot_err) along the way. This explains the function's unusually large size (2,460 bytes) — it's genuinely doing the work of several narrower accessors combined, not one simple property lookup.