4ef15a1dbe
Pure static analysis, no run spent. XObject::Wait's prologue does mov %rdi,%rbx at 8fbc9c, so the this pointer lives in a callee-saved register rather than a stack slot. And the binary carries full unwind information: .eh_frame with 127231 FDEs, which survives in Release builds because C++ exceptions need it, including an FDE covering 8fbc90 to 8fbde2 that tracks rbx explicitly. Together those mean that from a thread frozen deep in pthread_cond_wait, moving to the XObject::Wait frame and reading rbx yields the XObject being waited on -- gdb reconstructs callee-saved registers during the unwind from .eh_frame alone, with no DWARF involved. Reading the first quadword at that pointer gives the vtable, and vtable symbols are in the symtab, so the object's concrete type is identifiable too. This revises the previous entry, which listed route 1 as per-frame archaeology that must be redone whenever the binary changes, and route 2, a RelWithDebInfo rebuild, as what would make the question easy. Route 1 is neither expensive nor fragile: two gdb commands per thread, no rebuild, and the oracle stays byte-identical to the binary every other measurement in this corpus was taken against. Not yet executed on a frozen run, which is the next step and is now a small one.