Mail Archives: cygwin/2001/09/17/07:30:57
> -----Original Message-----
> From: Michael D. Crawford [mailto:crawford AT goingware DOT com]
> Sent: Monday, September 17, 2001 6:54 PM
> To: cygwin AT cygwin DOT com
> Subject: debugging threads in CygWin?
>
>
> I have a program written using Windows threads using the
> Win32 API with CygWin.
Cygwin or mingw aka gcc -mno-cygwin ?
> It's an application built with the ZooLib cross-platform
> applications framework,
> which you can get at http://zoolib.sourceforge.net/
This doesn't mention cygwin support from what I could easily see.
Correct cygwin support will require binding zoolib to Cygwin, as opposed
to win32.
> handling; I believe each time one steps gdb lets all the
> running threads
> continue to run and then stops them.
That wasn't my understanding, single stepping literally single steps.
continue will run all threads AFAIK. Still, you can check this by
looking into the Microsoft debugger API.
I know this is kind of vague but can anyone give me any
> suggestions on how to
> debug this?
Carefully :}. Seriously, if your goal is a cygwin-linked executable,
start off by porting zoolib. _Just compiling_ is not enough. Win32
primitives such as ReadFile and CreateThread cannot be used without
disabling someof cygwin's features. If your goal is a non-cygwin linked
executable, you'd be best off talking to the mingw list.
For the rest of this email I'm assuming you want a cygwin-linked exe.
Start by running the zoolib test suite. Get it to run with 0 failures.
Then look into your application. If zoolib doesn't have a test suite,
start one, with minimalistic bits taken from your application.
> I haven't done this but I understand single stepping through
> the assembly for atomic arithmetic can screw it up.
I don't see why it would. Atomic operations are single cpu commands, or
a set of cpu commands in a privileged mode that prevents the thread
getting interrupted. Both of those will prevent the debugger actually
stopping in the middle of the operation. The CPU has support for single
stepping machine code as well, saving the cpu state at each point, which
will allow inspection of everything, but AFAIK you will need a serial
debug terminal to do that, as the GUI and most of win32 is disabled at
that point.
> Something helpful I found tonight is that I can disable the
> use of COM by
> defining:
...
> The main think I need to do to get ZooLib built under CygWin
> is disable COM and
> comment off the places in ZooLib's code where it registers
> and unregisters its
> windows as drag & drop handlers.
Ah, no. The main thing is to build zoolib as UNIX and target XFree86, if
you want a working Zoolib without actual porting. Otherwise, I'll repeat
what I said before, port ZooLib. Compiling is not enough.
Rob
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -