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).
The
exit_groupsyscall, 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 handleexit_groupcorrectly may require significant emulation and replacement of Linux functionality, which is not Reverie's job.The problem comes from the fact that
exit_groupand 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_groupin 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: