From:	dagenais AT vlsi DOT polymtl DOT ca (Michel Dagenais)
Subject:	multi-thread debugging
6 Nov 1996 07:08:12 -0800 :
Sender:	daemon AT cygnus DOT com
Approved:	cygnus DOT gnu-win32 AT cygnus DOT com
Distribution:	cygnus
Message-ID:	<9611061423.AA21688.cygnus.gnu-win32@gutrune.vlsi.polymtl.ca>
Original-To:	gnu-win32 AT cygnus DOT com
Original-Sender:	owner-gnu-win32 AT cygnus DOT com

I had problems earlier interrupting a program in the debugger. It appears that
"console" programs can be interrupted fine, while "non console" programs
just cannot be interrupted.

Following my query about multi-threaded debugging, Stan Shebs replied:

> Probably not.  I say "probably" because gdb/win32-nat.c does include
> a small amount of thread-awareness, but it doesn't look complete, and
> nobody has worked on it recently.  Try it and let everybody know what
> happens... 1/2 :-)

And he was right. I can set a breakpoint in a different thread but the
debugger when stopping only shows me where the main thread is. By
using "set debugevents", we can see that the debugger receives events about
each thread being started. Apparently, the only part missing is to add the
threads to the list each time a new thread event is received, and to use
the correct stack when the debugger stops at a breakpoint or the gdb "thread"
command is used. Any hints about this. Is it likely that only a few
tens of lines are required to add the threads to the list and get the
pointer to the right thread stack? Which multi-threaded platform is likely
to be the best "model", lynxOs (lynx-nat.c), solaris, mach...?
-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".

- Raw text -