Tracee current working directory changes are not tracked

chdir and related syscalls are emulated so changes to the tracee cwd are not tracked. Since almost all syscalls depending on the cwd are also emulated, as far as I know, tracee replay behavior only depends on the cwd in one case --- execve. It's easy to write a testcase that does a chdir followed by an execve with a relative pathname, whose replay diverges because the exec which succeeded during recording fails during replay.

There's a related and in practice more serious problem, which is that currently if you record an executable with a relative path, change directory and then try to replay it, the replay will fail.

This is not simple to fix. Changing the path passed to execve during replay causes divergence because the process state is different after the exec. Changing the path passed to execve during recording (e.g. making it an absolute path) might change tracee behavior in unwanted ways. I developed a patch which records the cwd at the point of execve and forces a chdir to that directory when replaying the execve, but that's a bit ugly and fragile, because doing remote syscalls during an execve doesn't seem to work reliably.

My current plan is to create a temporary directory for each ReplaySession and make it the cwd for all processes in that session, always. When an execve is recorded we'll add a mmapped_file trace record with the absolute path of the exec'ed file. During replay of an execve, we know the path passed to execve and the absolute path of the executable we want it to resolve to. We can synthesize a filesystem subtree in and around the ReplaySession cwd (with the help of links) so that the execve path resolves to the desired file. When the execve has completed we can tear down this filesystem subtree.

Start by tracing the chdir and execve emulation paths, then review how ReplaySession establishes process state and how mmapped_file trace records are represented. Validate the behavior with cases covering chdir followed by execve with a relative pathname and replay of an executable recorded with a relative path. Done means both scenarios replay without divergence or failure.