This is a feature which Undo supports and I was hoping would get implemented into rr some day.
If the failure point is known to happen after a significant amount of multithreaded processing, it makes sense not to instrument/record that part and let the app run natively at full speed, utilizing all the CPU cores.
Then we can break before failure and start recording. Undo achieves this by having the user launch their interactive gdb session with a deferred recording option; the binary is then run with full speed; we break before failure, and issue a command which starts recording and makes us single-threaded and incur the recording performance hit. When time-travel debugging, it is obviously not possible to go before the start of recording, which is event 0.
This is a feature which Undo supports and I was hoping would get implemented into rr some day.
If the failure point is known to happen after a significant amount of multithreaded processing, it makes sense not to instrument/record that part and let the app run natively at full speed, utilizing all the CPU cores.
Then we can break before failure and start recording. Undo achieves this by having the user launch their interactive gdb session with a deferred recording option; the binary is then
run
with full speed; we break before failure, and issue a command which starts recording and makes us single-threaded and incur the recording performance hit. When time-travel debugging, it is obviously not possible to go before the start of recording, which is event 0.