Check if a CPU instruction has been used in a recording

When replaying a recording on a different machine, UDB can issue a warning about missing CPU features on that machine; this is because the machine where the recording was captured had a different CPU architecture (with usually more instruction sets) from the replay machine.


It would be useful if UDB could tell if the missing CPU instructions have actually been used during the recording (meaning that we’re unable to replay the recording on the other machine) or not (in which case, we could replay the recording on the other machine).

This is what UDB already does since version 6.0.


At record time, the Undo Engine keeps track of all the CPU features corresponding to instructions it encounters. When a LiveRecorder recording is saved, the features are saved in the recording’s header.

When you try to load a recording in UDB, UDB checks the features listed in the recording against the ones available on the current machine. If any required feature is not available, then UDB prints this and refuses to load the recording:

The recording cannot be replayed on this machine as it lacks some required features.


In  pre-6.0 versions, things worked differently, closer to what you say in your post. The Engine used to save the list of all CPU features available on the current machine.

As this check was far from perfect, we just reported a warning but still loaded the recording. This was  meant to warn the user that any SIGILL they could encounter was likely due to replaying the recording on a different CPU model.


If you try to load a pre-6.0 recording in UDB 6.0 or later and the CPU features don’t match, then you get a warnining like this:

No explicit CPU feature requirements are listed in
[…], but the process may have executed
instructions related to any of the following features that were
available on the hardware the recording was made on:

Could we have the engine create a small script when saving a recording that captures the CPU requirements to run the recording? So the engineer can just copy a small script to the machine they intend to use to replay, run the script and get a OK the recording will run here or NO, this machine lacks the capabilities to run the recording. So they don't have to copy a potentially big recording and get disappointed? 

It would be possible to do something like that, but there are many details to pay attention to.


For instance, if `live-record` generated the script, then it would be essential that both scripts and recording are preserved. Users could easily just copy the recording around and forget the script.


It would not be difficult to write a script which can analyse any recording and tell you the required CPU features, but this would need some of the internal machinery from UDB to work.

@mbarisione wrote:

It would not be difficult to write a script which can analyse any recording and tell you the required CPU features, but this would need some of the internal machinery from UDB to work.

I think this falls a little wide of the mark of what @dschwarz is suggesting.  If you have already gotten the recording onto the machine you might want to replay it on, in order to run this kind of tool, you’ve missed an opportunity to avoid moving a potentially huge file around, only to discover it won’t replay.  The script proposal is a small artefact which contains the information about what capabilities are required to replay a given recording and provides the ability to check whether any machine it is (cheaply) copied onto is capable of replaying.

An alternative might be to provide a tool which accepts a URI which may be remote, and checks whether the recording at that location can be replayed on the local machine (and perhaps if so copies the recording down for you and launches UDB, though that’s not necessary for MVP).  Provided only a small portion of the recording needs to be read (is the info in the header?) then this script will be quick to report a negative.  It’s still not perfect as it requires the user to have a means for us to access the remote file...but perhaps we could pull enough over ssh/nfs without needing the whole file copied over up-front.

Thinking about it further...could udb itself just do that, if we made udb do the check early then prompt the user whether they want to proceed with loading the file?

Updated idea statusNewDiscussion ongoing

Could recording-dump be extended so it can be pointed at a recording and have it output a compatibility testing script which can be run on the desired replay machine?  This way there is no 2nd script you need to preserve with the recording, but uploading a <2MB tool to the host with the recording, generating this compatibility test script, and downloading the script should be possible.

Alternatively, we could add a replay-test script which could ship with UDB, which you copy/paste some instruction utilisation output from recording-dump into, and it validates whether the host could replay this recording.  Again avoiding the need to move the recording until it is confirmed it can be replayed?