Thread Debugger - Spec?!
sudhir halbhavi
We are trying to implement a debugger for user space threads (pthreads).
All the info I have regarding their requirements and design are from
the papers on pthreads and solaris threads, which is minimal.
We would like to hear from people who have actually programmed using
threads and what they would like to see in a threads debugger.
We are planning to do this on Linux and make it public domain.
Thanx for any input.
Sudhir
Samuel Tardieu
Sudhir> Hi We are trying to implement a debugger for user space
Sudhir> threads (pthreads). All the info I have regarding their
Sudhir> requirements and design are from the papers on pthreads and
Sudhir> solaris threads, which is minimal.
[...]
Sudhir> We are planning to do this on Linux and make it public
Sudhir> domain.
Latest releases of GDB already have thread support, you may want to
have a look at this. It lacks pthreads support, so feel free to add it :)
Sam
--
"La cervelle des petits enfants, ca doit avoir comme un petit gout de noisette"
Charles Baudelaire
Claudio Fleiner
>All the info I have regarding their requirements and design are from
>the papers on pthreads and solaris threads, which is minimal.
>
> We would like to hear from people who have actually programmed using
>threads and what they would like to see in a threads debugger.
>
>
Note: Could you please correct the mail address in your posts? I tried to
send you mail and it bounced.
I am currently implementing the runtime support for a new parallel
language called pSather (see http://www.icsi.berkeley.edu/Sather/index.html).
We work extensivley with threads and I have big problems to debug
the runtime. The best way currently is to use the lwp-thread package of Stephen
Crane, which is not preemptive and works quite well with gdb.
I would be very interested in your work, especially as we will need
a debugger for pSather too. Here some things I would like to able to do:
- switch from one thread to another
- display stack traces of all threads
- show which threads are waiting for which locks/semaphores/systemcalls
to return
- lock and unlock any lock / signal and wait on any semaphore /....
- kill a thread / create a new thread / suspend a thread
- have breakpoints per thread (example: break on function foo, but only
if thead t1 calls it).
- if the debugger stops a thread, all other threads should stop too, or
should be able to still continue.
- Debug different threads in different windows
- support per thread signals and longjmps
- detect deadlocks and race conditions
- be able to connect to a running process as it is possible today with gdb
- I would like to be able to run a progam which generates a trace,
and then replay exactly what happened (you would need compiler support
for this)
I think that may keep you busy for some time :-)
Claudio
--
----------------------------------------------------------------------
Claudio Fleiner fle...@icsi.berkeley.edu
International Computer Science Institute, 1947 Center Street, Berkeley
Tel: (510) 643-9153, Fax: (510) 643-7684
Roy Gordon
> a debugger for pSather too. Here some things I would like to able to do:
> - if the debugger stops a thread, all other threads should stop too, or
> should be able to still continue.
The other side of this is needed too:
when continuing or stepping from a breakpoint specify which
other threads that are to continue.
It is important to be able to hold other threads constant (e.g. stopped)
while continuing the one (or ones) you are working on. Having them all
continue is also needed, obviously.
-- roy