From: dagenais@vlsi.polymtl.ca (Michel Dagenais) Subject: Re: multi-thread debugging 7 Nov 1996 08:46:43 -0800 Sender: daemon@cygnus.com Approved: cygnus.gnu-win32@cygnus.com Distribution: cygnus Message-ID: <9611071548.AA28458.cygnus.gnu-win32@gutrune.vlsi.polymtl.ca> Original-To: root@jacob.remcomp.fr Original-Cc: gnu-win32@cygnus.com In-Reply-To: (root@jacob.remcomp.fr) Original-Sender: owner-gnu-win32@cygnus.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@cygnus.com" with one line of text: "help".