Pernosco Blog

rr Trace Portability: TZCNT

When we introduced trace portability to rr our primary goal was to enable use cases like Pernosco, where traces would be recorded on one machine and replayed on another for advanced analysis. At the time it was an open question exactly how portable these traces would be, but for the most part the x86 architecture is well behaved enough that things just work. As Pernosco usage has grown we have ingested traces from a larger collection of systems and discovered a few subtle differences. We have previously written about emulating RSQRTTSS and other "approximate" floating point instructions which produce different results on Intel and AMD processors. The most recent issue we've come across is related to the TZCNT instruction.


Debugging Dataflow Through Pipes And Sockets

One of the most powerful features of the Pernosco Omniscient Debugger is using dataflow analysis to track a value back to its origin. We recently made this even more powerful, by giving it the ability to track values that flow through pipes and through sockets (when traces are recorded with rr 5.5).


Structured Identifiers

Source-level debuggers devote much interface real estate to program identifiers. To avoid ambiguity we often want to display fully qualified identifiers (e.g. including namespace/module names and the parameters of generic types), but these are often very long and unnecessarily verbose. Pernosco takes advantage of interactivity by eliding selected parts of complex identifiers; clicking on an elided part reveals elided text (which may contain nested elided parts). This requires treating identifiers not as plain strings, but as syntax trees — structured identifiers. This need to obtain structured identifiers has implications for the design and implementation of debuginfo formats and demangling APIs.

← Newer Posts