observe & control thread state for exit futex ?
How can a debugger, newly attached to an arbitrary thread, determine whether the thread has a pending exit futex and associated memory location to clear [CLONE_CHILD_CLEARTID flag and child_tid_ptr parameter at __clone()]?
If so, then how can the debugger determine the address, change the address, cancel the futex, and/or intercept the notification?
Quoted 6 lines · John Reiser
How can a debugger, newly attached to an arbitrary thread, determine whether the thread has a pending exit futex and associated memory location to clear [
CLONE_CHILD_CLEARTIDflag andchild_tid_ptrparameter at__clone()]?If so, then how can the debugger determine the address, change the address, cancel the futex, and/or intercept the notification?
It can't. Even clone flags are not accessible.
If you can think of a good reason that a debugger would need any particular piece of data, exposing it is very straightforward.
Signature · 2 lines
Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Quoted 6 lines · Daniel Jacobowitz
Quoted 4 lines · John Reiser
How can a debugger, newly attached to an arbitrary thread, determine whether the thread has a pending exit futex and associated memory location to clear [
CLONE_CHILD_CLEARTIDflag andchild_tid_ptrparameter at__clone()]?
Quoted 9 lines
Quoted 2 lines
If so, then how can the debugger determine the address, change the address, cancel the futex, and/or intercept the notification?
It can't. Even clone flags are not accessible.
If you can think of a good reason that a debugger would need any particular piece of data, exposing it is very straightforward.
The debugger needs this information to determine the state of the thread. An automated software audit program needs the information to verify that threads are working correctly. In general, write-only state [from the viewpoint of the thread] is a bad idea.
Would a new option to sys_prctl() be a good way to expose the data?