tui for headless ida https://git.sl0p.foo/ida-tui.git/atom/idatui/trace.py?h=main 2026-07-27T19:50:07Z 2026-07-27T19:50:07Z blasty blasty@local 2026-07-27T19:50:07Z urn:sha1:1e84c0e79ed76b19923caab250189c17464a5287 Both code views now show where you came from and where you're going: the instruction you're on ('now'), the ~96 steps behind it ('past', warm) and the ~96 ahead ('future', cool). A trail, not all of history. Painting every address the trace ever touched says almost nothing on a loop-heavy program; the last and next few dozen steps say how you GOT here. Where an address appears on both sides — a loop body, which is most of them — the nearer side wins, because that's the one explaining the step you just took or are about to. **The pseudocode is painted too**, which is the reason to build this here rather than use Tenet. A trace records instructions, so that's what Tenet paints. We already have decomp_map from the split-view work, saying which instructions each C line covers, so the same trail lands on the decompilation: line 46 now | v3 = getenv("POSIXLY_CORRECT"); line 47 future | v4 = (__int64)*a2; line 49 future | if ( v3 ) A C line covers many instructions, so it takes the strongest kind present: now beats past beats future — if the instruction you're standing on belongs to this line, this line is where you are. Two things kept cheap: the trail is recomputed per SEEK rather than per repaint (~200 lookups, and repaints vastly outnumber steps), and decomp_map is cached per function because it's an RPC and stepping is interactive. The colours sit deliberately under the code palette — the trail says "you came through here", the text still has to read as code. tests: +8 UI (21) — the listing carries now/past/future and it reaches the screen; pseudocode is painted; exactly ONE C line is 'now' and it is the line covering the current instruction (not merely some executed line, which is the mistake this check exists to catch). 209/0 scenarios, 27/0 model, 10/0 diff. 2026-07-27T19:32:24Z blasty blasty@local 2026-07-27T19:32:24Z urn:sha1:713bed2864b755c4e83ab55c6e5726216cc812bf First slice of the execution-trace viewer: parse, index and query a Tenet trace. No UI yet — this is the layer everything else stands on, and its shape decides whether decompiler painting is cheap later. A Tenet trace is a line-per-instruction delta log: registers that changed, the PC every line, and each memory access WITH its bytes. That's enough to reconstruct any register or address at any point in time, in either direction. Our own reader, not a port. The reference (tenet-original) packs traces into segments with compressed address/mask tables, which earns its keep for its Qt timeline; we need different queries and would rather own ~400 lines than inherit 3700. Indexed around the query the UI actually asks, which the reference answers one address at a time: WHICH TIMESTAMPS EXECUTED THIS SET OF ADDRESSES. A listing row is one address, but a pseudocode line covers many (we already have decomp_map for that), so by_ip maps address -> timestamps and hits() takes a set. Painting a pseudocode line will be one call, not one per instruction. Registers are stored as per-register change points, so a value at time t is a bisect, and "which instruction set this register?" (last_write) is the same lookup — that being the question a trace explorer exists to answer. Rebasing is not optional: our echo trace runs at 0x7ffff6faa000 while the database has that code at 0x2490. Page offsets survive relocation, so the low 12 bits of an instruction address are invariant; bucket the database's addresses by those bits and take the slide the most trace addresses agree on. Verified against a real IDB: slide -0x7ffff6fa8000, and it picks out the 12 functions the trace actually entered (main, start, ...) from 128. Performance: 176k instructions parse in 350ms (~500k lines/s), so a 10M-line trace is ~20s and wants a progress callback, which load() takes. FOUND A BUG IN THE REFERENCE while building the differential test. A register written on the LAST line of a 65535-line segment is missing from the next segment's base state, so Tenet returns a stale value until that register is written again — measured: wrong for all 179 timestamps of one such window. It survives in the reference because it only shows when the register isn't rewritten immediately. That changed how the test works. Rather than "must agree with the reference", it ARBITRATES with the raw text when they differ: if the text backs us it's reported and allowed, if the text backs them it fails. Blanket agreement would have made us copy their bug to stay green. tests: test_trace.py (27, pure stdlib) covers reconstruction, the set queries, rebasing (including that a lone agreeing address is not enough, and that matching is on page offsets rather than addresses looking plausible) and malformed input; test_trace_vs_tenet.py (10) diffs against the reference on real traces.