How to expose exit_group events in reverie

[rrnewton]

The exit_group syscall, as discussed in this dettrace issue provides a challenging case for the separation of concerns in Reveries design. That is, Reverie strives to be the interception/instrumentation layer only, separate from any higher level tools that provide kernel-like functionality, but to handle exit_group correctly may require significant emulation and replacement of Linux functionality, which is not Reverie's job.

The problem comes from the fact that exit_group and ptrace don't mix well [1]. A Reverie guarantee should be that it detects exit events for every thread. If ptrace gets into a messed state where it can't reliably tell if a thread has exited, that undermines this goal.

Intercept exit_group but don't inject it

This essentially forces the tool sitting above Reverie to emulate exit group, because it can't inject it back into the guest, and therefore can never actually execute exit_group in the kernel.

Alternative: Emulate/hide exit_group at the Reverie level

Another possibility is that Reverie itself tracks enough information that it can essentially "expand" exit group into a series of individual, asynchronous thread exit events. The problem with this is that it takes away any ability of the tool to control when these exits occur (unless the tool is fully sequentializing scheduling).

Other References:

• [1] Baojun's blog post
• Discussion in strace which includes the comment/claim:

When any thread executes exit_group syscall, every tracee in its thread
group reports its death to its tracer.