Add question-oriented emulator C++ probe - #1388
Draft
andrewboudreau wants to merge 2 commits into
Draft
Conversation
✅ PR validation — Passednoverify: no source/build-data changes in this PR Each changed |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
tools/trace/cpp_probe.py, a question-oriented runtime probe for readable-C++ reconstructionCPP_PROBE_JOB.mdhandoff for assigning real emulator investigationsWhy
Decompiler output establishes the instruction stream, but it is awkward for runtime-observable questions such as which concrete object reaches a method, which fields change, and what values a candidate timer or fixed-point field takes in gameplay. This adds a narrow evidence-gathering layer while keeping byte matching and relocation verification as the source gates.
Validation
python -m pytest tools/test_trace_cpp_probe.py: 11 passedpython -m pytest tools: 277 passed, 3 skippedpython tools/rombuild.py -j 16 --no-rom: 10,813/10,813 reproducing, 106/106 modules exactport_refcheck: 393 references checked, all resolvedLive emulator validation
An isolated melonDS 1.1 session captured
Fader::AdvanceInterpfor 900 entry/return pairs with a ROM-clean canary, no overlay rejects, and one stable object/vtable. The observed idle endpoint heldcurrInterp=0,speed=-1.0, returned true, and did not write the object. A separate setter probe recorded zero hits on the exercised path; that is retained as a negative observation, not interpreted as proof that the setter is unused.The live report exposed and now covers an adjacent-function bug in vtable slot naming: concrete function pointers resolve at their exact address, while only link-register caller resolution subtracts the ARM/Thumb call width. Reports also label classes recovered from slot methods as method-owner hints rather than concrete-type proof, and summarize entry
r0-r3values for argument questions.