0120677722
Two corrections to the plan the freeze file leaves for the next pass, both cheap to establish and both worth having before a run is spent discovering them. The export in the frozen frame is confirmed. The shim frame carries its ordinal as a template parameter, 176 decimal, which is 0xB0, and xboxkrnl_table.inc line 190 maps that to KeWaitForSingleObject. The identification was previously read off frame names; it is now pinned by ordinal. The file's stated next step does not work on this binary. It says the wait target is one info-args-equivalent away now that a debugger can be attached, but readelf shows zero debug sections and only a symtab of 27807 entries. The Release build is not stripped, which is why frames carry function names, but it has no debug info at all, so gdb can name a frame and nothing inside it: no info args, no p *this, no member access. The earlier note conflated "not stripped" with "has debug info". Two routes remain and their costs are now recorded. A prologue-guided stack read can recover XObject::Wait's spilled this pointer from a known stack slot, needing no rebuild and keeping the oracle byte-identical to the one every other measurement in this corpus used, at the price of per-frame archaeology that must be redone if the binary changes. Alternatively a RelWithDebInfo build via build-canary makes this and every future freeze question straightforward, at the price of a full compile and a binary that differs from the measured one. Neither is attempted here. Recorded so the next pass picks with the costs visible.