From:	dagenais AT vlsi DOT polymtl DOT ca (Michel Dagenais)
Subject:	Re: multi-thread debugging
7 Nov 1996 08:46:43 -0800 :
Sender:	daemon AT cygnus DOT com
Approved:	cygnus DOT gnu-win32 AT cygnus DOT com
Distribution:	cygnus
Message-ID:	<9611071548.AA28458.cygnus.gnu-win32@gutrune.vlsi.polymtl.ca>
Original-To:	root AT jacob DOT remcomp DOT fr
Original-Cc:	gnu-win32 AT cygnus DOT com
In-Reply-To:	<m0vLFZy-000ALAC@jacob.remcomp.fr> (root@jacob.remcomp.fr)
Original-Sender:	owner-gnu-win32 AT cygnus DOT com

   I am still writing my debugger, and in this context, I just do that for each
   thread: When I receive the event that a thread starts, I store the
   info to be able to switch to the good context later. This looks very easy
   to say, but not so easy to do... If it is not done in gdb is because of that
   I suppose... You have to handle thread termination and do the cleanup too of
   course.

   In this 'context', I would like to know how gdb solves the problem of a trap in 
   ntdll.dll for instance. Problem is, ebp (the frame pointer) is used in that
   dll as a normal register, and can have values that do not point to the current
   stack frame at all, mainly because there is no stack frame! it has been optimized
   in hand-written assembly! I haven't found any solution for this problem.

I just want to be able to debug some heavily multi-threaded programs under
NT, generated by gcc. Even if i cannot "break" into dll it will still be
useful. My hope is to spend as little time as possible in gdb to achieve
that...

I saw your postings about lcc. If the lcc environment eventually surpasses
gcc/gdb in terms of functionality and platform support, it could be
a possibility to switch to lcc instead of gcc as a backend for Modula-3.
I vaguely remember that lcc was used in some universities in the US but
dont remember its advantages over gcc, copyright...
-
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 -