An amazing project. Would it be possible to get to a certain point in a trace, then switch the process back into "live mode" so that further inputs could be made into the program? This could open up all sorts of interesting things, like recording interactions with web applications and then allowing a developer to open up high-level JS/DOM debugging tools to see exactly what went wrong without needing to worry about replicating the exact input sequence that led up to the bug.
It's unfortunate that the no-shared-memory limitation is so hard-baked in, so it would seem that things like Chrome rendering processes wouldn't play nicely with rr (I'm assuming they communicate with shared memory, correctly if I'm wrong!).
As I understand, you can't "go live" with the current architecture. In replay, no system call is executed. Write is no-op. Read is done from the trace. This is how PTRACE_SYSEMU works. To "go live", you would need to actually execute system calls.
It's unfortunate that the no-shared-memory limitation is so hard-baked in, so it would seem that things like Chrome rendering processes wouldn't play nicely with rr (I'm assuming they communicate with shared memory, correctly if I'm wrong!).