The Undo Engine divides the execution history of a program into BBs, units of execution consisting of deterministic operations, and in which each program counter value appears at most once. A BB is broadly analogous to a basic block.
A time in execution history is specified as a bbcount (representing the start of the BB) or,
more specifically, as bbcount:pc (representing a program counter value within the
BB). bbcount is represented by an integer starting at
1 and increasing as execution progresses.
UDB accepts commas in the bbcount, so you can insert them to make a
bbcount more readable. For example,
the same bbcount.
This concept of time is unrelated to wall-clock time. For example, if a
program is blocked in a call to
sleep(), the bbcount does not increment
as no instructions are being executed.
info time [-a]¶
The current time in execution history.
This is the number of BBs that the program has executed (the bbcount).
Append the program counter value.
For example:5% 11,573> info time Current time is: 11,573 (in recorded range: [1 - 228,445]) 5% 11,573> info time -a Current time is: 11,573:0x5555555552df (in recorded range: [1 - 228,445])
ugo time bbcount[:pc]¶
Jump to a time in the program’s execution history.
Specify the time as bbcount to jump to the start of a BB, or as bbcount:pc to jump to a program counter value in a BB.
If bbcount is beyond the end of execution history, the program switches to record mode if necesary and continues execution until the specified bbcount is reached, or the program finishes, or a breakpoint is hit.
If the program does not reach the specified pc in the given bbcount, the time-travel operation fails.
For example:5% 11,573> ugo time 5 elf_get_dynamic_info (static_pie_bootstrap=false, bootstrap=true, l=0x7ffff7ffdad0 <_rtld_global+2736>) at ./get-dynamic-info.h:68 68 ./get-dynamic-info.h: No such file or directory. 0% 5> ugo time 11,573:0x5555555552df main () at cache.c:71 71 if (i % 100 == 0)
The reasons for representing time using the bbcount:pc notation are:
Precision and unambiguity: each executed instruction in a program corresponds to a unique time in the program’s execution history.
Performance: it’s easy to determine the bbcount and program counter, without the need for an expensive system call.
Convenience: it’s easy to compare two times in bbcount:pc notation.
Concision: in most cases the bbcount alone is sufficient to identify a time of interest.
There is no guarantee that different runs of a program will execute the same sequence of BBs. Non-deterministic events such as address space layout randomization, signal delivery, thread switches, and so on, may cause the execution flow to be different from run to run.