Firmware Fn UpdateSettingsDueToDVDChange

UpdateSettingsDueToDVDChange — CArr_AdasMain::UpdateSettingsDueToDVDChange

Part of Firmware Reversing.

• File offset: 0x751560 (VA 0xf6fdf254)
• Status: 🟡* Partially traced — a short, clean, real function (40 bytes), but it too ends with the same "no locally-visible blr" anomaly documented on Firmware Reversing — the frame is popped (addi r1,r1,0x10) but no blr follows; instead the usual <data> word-pair, then different code continues with no fresh stwu/mflr prologue of its own either. This is the specific function used to resolve the "is it code or data" question via real CPU emulation (Unicorn Engine, PPC32 big-endian) — single- stepping a real execution confirms every instruction through the frame-pop runs correctly, then the CPU raises a genuine illegal- instruction exception the instant it tries to execute the word right after (00130019) — not a disassembler gap, real non-code data, confirmed independently of capstone (and the word's own primary opcode field is 0, a value never allocated on any real Power ISA implementation — ruling out even an exotic/vendor-specific valid encoding). Follow-up, same tooling: manually skipping exactly 8 bytes and resuming execution (with the ENTIRE 24MB native region mapped from the real file this time, so nothing faults purely from missing context) runs 5 further real, valid instructions cleanly — confirming genuine, well-formed machine code really does resume immediately after an 8-byte gap here. That code (stw r30,8(r1) / stw r31,0xc(r1) / stw r0,0x14(r1) / ...) writes to stack offsets BEYOND the 8 bytes this function's own small frame reserved — i.e. it's reusing space in the just-popped (caller's) frame rather than establishing a fresh one of its own, consistent with a shared trampoline/stub mechanism rather than an independent function. Where that stub leads (it next loads a global pointer and branches on it) wasn't chased further — the specific address it computed in this test is an artifact of synthetic register state, not trustworthy without the function's real caller context.
• Full mangled name: UpdateSettingsDueToDVDChange__13CArr_AdasMain (no explicit arguments beyond this/implicit arg2)

Real, confirmed behavior

UpdateSettingsDueToDVDChange(this, flag): if flag == 0xffff AND this != 0, calls the destructor of a real CfcMdlMsgModelDeregisterForAspect object — i.e. on a specific sentinel condition (map/DVD disc change, per the function's own real name), it deregisters a model/aspect-change subscription. Otherwise does nothing.

Confirms the ADAS subsystem reacts to disc changes by tearing down (at least) one real message-model subscription — consistent with ADAS map-matching data needing to be re-synced whenever the underlying map disc changes.

This is now the 5th/6th real confirmed instance of the "no locally-visible blr" anomaly (alongside getNodeVidArmMP0, getIndexOfVid, filterToggleSeg, addSegmentData, and TransformHeadingAngleRelative) — confirms this is pervasive across the whole 24MB region, not a rare edge case limited to a handful of functions.