A first pass at implementing thread stop and continue on FreeBSD.
authorDan McNulty <mcnulty@cs.wisc.edu>
Mon, 5 Jul 2010 16:11:01 +0000 (11:11 -0500)
committerDan McNulty <mcnulty@cs.wisc.edu>
Mon, 5 Jul 2010 16:11:01 +0000 (11:11 -0500)
commitdde1ff0027a8308e18fbcea68347fc7647b6b756
treeead8f4a54b7c1fef304d7a1f4abf02f2157dbc8e
parent9b70e248fb77a5502d4ac0007d90d306656e3ebe
A first pass at implementing thread stop and continue on FreeBSD.

Includes a bug fix in HandlePostExit, a int_process was being deleted and still
being used. The debugging printf didn't match the actual behavior.

Includes some reworking on thread_db classes.

A majority of this commit deals with FreeBSD's "interesting" thread control
model via ptrace.

To stop a thread, a SIGSTOP is sent to the thread in the process. The entire
process stops and the thread can then be suspend with a call to ptrace with the
request PT_SUSPEND. The entire process is then continued, but the suspended
thread will not run.

To continue a suspended thread in a running process, a SIGSTOP is sent to any
running thread in the process. The entire process stops and the thread
to-be-continued can then be resumed with a call to ptrace with the request
PT_RESUME. At this point, the entire process is continued.

There are a few changes to the platform-independent code to incorporate this
thread control model via ptrace.

The first is a new internal event, EventContinue.  This is generated when a
SIGSTOP is used to resume a suspended thread. Also, int_thread's now have a
fields to represent a pending continue and a pending user continue. User
continues are differentiated from internal continues because internal continues
need to be batched to avoid race conditions between the generator and handler.
The plat_cont function now basically calls ptrace with the request of PT_RESUME
with some added logic for user and internal continues.  The process is
continued later in waitAndHandleEvents after syncRunState is called. This
continue occurs via a new platform-dependent function, plat_contProcess. It
should be a no-op on other platforms that don't need it.

It is now possible to have pending continues similar to pending stops. A
pending continue is handled in int_process code in exactly the same way as a
pending stop.

To stop this continue from being called on other platforms, the
independentLWPControl function was renamed to getThreadControlMode and it now
returns an enum for the three case: NoLWPControl, HybridLWPControl (FreeBSD),
IndependentLWPControl (Linux).

Processes now have a field for the continue signal because on FreeBSD, threads
cannot be continued with there own signals; only the process can be continued
with a signal. The threads set the parent process' continue signal when
approriate.
12 files changed:
proccontrol/amd64-unknown-freebsd7.2/Makefile
proccontrol/h/Event.h
proccontrol/h/EventType.h
proccontrol/i386-unknown-freebsd8.0/Makefile
proccontrol/src/event.C
proccontrol/src/freebsd.C
proccontrol/src/freebsd.h
proccontrol/src/handler.C
proccontrol/src/int_process.h
proccontrol/src/int_thread_db.C
proccontrol/src/int_thread_db.h
proccontrol/src/process.C