[comp.parallel] Summary -- multi-thread debugging

kenton@decwrl.dec.com (Jeff Kenton OSG/UEG) (04/19/91)

I recently posted a request for suggested features needed
by a debugger (and the kernel) to debug multi-threaded
programs.

The number of "me-too" responses I got indicates that there
is more interest than available information.  Still, I got
a number of informative replies.  Thanks.

-----------------

Depends what features you have in the input language.  Here
at CSRD we use Cedar Fortran to write programs for a shared
memory parallel machine.  This language allows nondeterminacy
in the program output.  Since no serious debugging, i.e. for
arithmetic and logical errors can be done until atleast the
program is determinate, we are concentrating on a system that
automatically detects nondeterminacy in parallel programs.
The idea is that only after nondeterminacy has been detected
and eliminated can arithmetic and logical debugging begin.

-----------------

As far as parallel debugging goes, the big thing we did was to provide for
ptrace by unrelated processes.  Sun also does this.  That feature, plus proper
locking, is about all we did in the kernel for parallel debugging.

-----------------

I suggest looking at the following paper which contains excellent suggestions
for debugging multithreaded kernels and programs

@inproceedings{Redell88,
	author = "David D. Redell",
	title = "Experience with {Topaz} TeleDebugging",
	pages = "35--44",
	booktitle = "Proc. of the SIGPLAN/SIGOPS Workshop on Parallel and 
		Distributed Debugging",
	note = "Special issue of SIGPLAN Notices, 24(1), Jan. 1989.",
	address = "Madison, WI",
	month = may,
	year = 1988 }

-----------------

I went to the trouble of parallelizing the interpreter for
my debugger, only to find out you really don't need it:

you need:

1) some way to stop the execution of all threads (easy)
2) some way to extract the fp & sp (and the arg ptr if you
   cant get it from the fp & sp) from all threads.
3) some way to print out the stack trace, given a sp, fp, & ap.
4) If you're writing a symbolic debugger, some way to load
   the scope of any stack frame within a stack trace
5) information as to the staus of each thread.  If you're using
   a thread library as opposed to extensive OS control, this
   is as simple as having access to each task record in the
   program.

I"m screwed because I'm on a multiporcessor, and the OS only
saves the registers for a sinlge proc, then lets it enter the
interrupt handler, while the other processors sit in the kernel,
where I can't get their fp & sp.

-----------------

Check out the NeXT debugger...

-----------------



-----------------------------------------------------------------------------
==	jeff kenton		Consulting at kenton@decvax.dec.com        ==
==	(617) 894-4508			(603) 881-0011			   ==
-----------------------------------------------------------------------------

-- 
=========================== MODERATOR ==============================
Steve Stevenson                            {steve,fpst}@hubcap.clemson.edu
Department of Computer Science,            comp.parallel
Clemson University, Clemson, SC 29634-1906 (803)656-5880.mabell