From f4630be2da880011598a3f4d5722e38aedaa636a Mon Sep 17 00:00:00 2001 From: blasty Date: Tue, 28 Jul 2026 15:06:31 +0200 Subject: trace: a step in split view moves the listing cursor to the pc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Normal navigation moves one pane and gives the companion a band, never a cursor — that rule exists so the two can't chase each other. A trace step isn't navigation: time is a single global position and both panes are showing the same instant, so the cursor belongs on it in both. _seek_split places the listing cursor on the current instruction, then hands off to the existing _sync_split so the companion still gets its band and align() at the driver's screen row. The anchoring machinery is used, not bypassed. PARTIAL, and the shortfall is worth stating plainly: the LISTING cursor tracks the pc reliably (tested over consecutive steps). The PSEUDOCODE cursor only follows when decomp_map covers that address, and for cat's main it covers almost nothing — four entries for a 700-line function. That is not something this commit introduced and not something I could fix responsibly without understanding it; TODO has what I measured, including that dec.goto(96) left the cursor at 0 in the same run, which may or may not be the same bug. One real fix along the way: _place_decomp_at prefers the map the trail painting keeps (keyed to the decompiler's currently loaded function) over the split view's _split_ea2line. The latter is refreshed by a guarded async path that drops its result if _cur moved while in flight, and a burst of steps moves _cur constantly — so during stepping it is frequently a map of the function you just left. tests: +2 trace UI (25) — stepping in split moves the listing cursor onto the pc for six consecutive steps, and the trail marks it 'now' in both panes. 212/0 scenarios. --- TODO | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) (limited to 'TODO') diff --git a/TODO b/TODO index 90da191..679318c 100644 --- a/TODO +++ b/TODO @@ -88,3 +88,32 @@ The general rule this came from: a suite whose result depends on its own history can't be trusted to accuse the code. tests/test_blob_ui.py builds a throwaway binary; test_project_ui.py stages copies; test_thumb_ui.py deletes the .i64 before each phase because the T flag and segment bitness are SAVED in it. + +## decomp_map returns almost nothing for some functions (blocks split stepping) + +Found while making a trace step move BOTH cursors in split view. For cat's +main() — 700+ pseudocode lines — decomp_map() came back with FOUR entries, so +almost no instruction address maps to a C line and the pseudocode cursor can't +follow the program counter. On echo's main the same call maps plenty (the trail +painting test relies on it), so it is function- or timing-dependent, not simply +broken. + +Two things to separate when picking this up: + +* Is the map itself sparse (the tool's item.dstr() walk missing most items for + this function), or is it being FETCHED at a moment when the decompiler has a + different function loaded? _trail_map_ea and dec.loaded_ea both read 0x24a0 + when it happened, which argues for the former. +* dec.goto(96) left dec.cursor at 0 in the same run. That may be a symptom of + the same confusion (a stale/short _strips) or an independent bug. Check it on + its own before assuming. + +Also noticed: _split_ea2line is refreshed by a guarded async path +(_apply_split_map drops its result if _cur moved while in flight). A burst of +trace steps moves _cur constantly, so during stepping it is frequently the map +of the function you just left. _place_decomp_at now prefers the trail's map for +that reason, but the split view's own sync still uses the laggy one. + +Consequence today: in split view a trace step moves the LISTING cursor onto the +current instruction (works, tested) but the pseudocode cursor only follows when +the map happens to cover that address. -- cgit v1.3.1-sl0p