RE: debugging threads in CygWin?

RE: debugging threads in CygWin?

[Michael D. Crawford]

Thanks for responding.

(I hope this isn't posted as HTML I haven't figured out how to disable 
HTML mail in
Mozilla).


ZooLib is a cross-platform application framework that presently works on 
Win32,
Linux with X11, BeOS x86 and classic Mac OS, with Mac OS X nearly there.

I'm trying to build it under CygWin, but without using the cygwin.dll. 
 I want to be
able to run native Win32 applications built this way.

Presently it works to build it on Win32 with Metrowerks CodeWarrior, and 
in the
development version it also can build with Microsoft Visual C++.  I'd 
like to enable it
to be built with g++ on CygWin as well, as I feel this would foster its 
use in more
Free Software development.

I'm putting these options on the g++ command line:

-D_REENTRANT -Wl,--subsystem,windows -mwindows

It should be possible to build ZooLib applications as X applications 
under CygWin as you suggest, but then this would require an X server and 
would involve a great deal
of extra labor on the part of the machine.

As it is ZooLib makes only very primitive use of the GUI facilities 
provided by the
host, I think I should be able to do this targeting Win32 directly.

Is there something more I need to do to disable the use of the 
Cygwin.dll?  I remember
somewhere reading that one can do this.

I wasn't trying to use mingw.  I plan to install mingw as a separate 
build system and
get that to work after I get the cygwin builds working.

Much later I'm going to try to get it to build as a Carbon app using g++ 
on Mac OS X.

Also you said that the zoolib web site doesn't mention Cygwin support. 
 It doesn't yet
because I'm doing it.  I wrote the zoolib web site, as part of my effort 
to help
ZooLib author Andy Green to get ZooLib released as open source.

Mike
crawford@goingware.com
http://www.goingware.com/



--
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/

Re: debugging threads in CygWin?

[Robert Collins]

----- Original Message -----
From: "Michael D. Crawford" <crawford@goingware.com>
To: <cygwin@cygwin.com>
Sent: Monday, September 17, 2001 10:02 PM
Subject: RE: debugging threads in CygWin?


> Thanks for responding.

No probs, sorry for the delay this time around.


> I'm trying to build it under CygWin, but without using the cygwin.dll.
>  I want to be
> able to run native Win32 applications built this way.

You need to pass -mno-cygwin to gcc and g++. You also need to make a
couple of changes to correctly support -mno-cygwin with g++. See this
lists archives (search for g++ should find the reference fairly
recently).

> I'm putting these options on the g++ command line:
>
> -D_REENTRANT -Wl,--subsystem,windows -mwindows

See above.

> It should be possible to build ZooLib applications as X applications
> under CygWin as you suggest, but then this would require an X server
and
> would involve a great deal
> of extra labor on the part of the machine.

Not that much actually :]. The rendering only gets done once after all.

> I wasn't trying to use mingw.  I plan to install mingw as a separate
> build system and
> get that to work after I get the cygwin builds working.

cygwin without linking to cygwin1.dll == mingw. (approximately). The
mingw compiler uses win32 paths, not unix style paths, but thats about
the only difference if the appropriate libraries are present. (I may get
corrected on this point :]).

> Also you said that the zoolib web site doesn't mention Cygwin support.

If you build without linking to cygwin1.dll, you are not creating cygwin
support. You can use Win32 calls from cygwin linked programs (as XFree86
does), but some of the cygwin support is unable to work correctly when
you do so - depending on the calls made. (i.e. if you use ReadFile
instead of read(), cygwin cannot deliver signals to your thread).

Cygwin has support for pthreads, and I recommend you use that rather
than win32 threads.

>  It doesn't yet because I'm doing it.  I wrote the zoolib web site, as
part
> of my effort  to help ZooLib author Andy Green to get ZooLib released
as open source.

Cool. Well we'll help you help Andy :].

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/

RE: debugging threads in CygWin?

[Robert Collins]

> -----Original Message-----
> From: Michael D. Crawford [ mailto:crawford@goingware.com ]
> Sent: Monday, September 17, 2001 6:54 PM
> To: cygwin@cygwin.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/

debugging threads in CygWin?

[Michael D. Crawford]

I have a program written using Windows threads using the Win32 API with CygWin. 
It's an application built with the ZooLib cross-platform applications framework,
which you can get at http://zoolib.sourceforge.net/

It uses threads (in a C++ wrapper) and atomic math extensively.  The atomic math
is written in inline assembler, with a different version provided for each
supported compiler and processor.

I have it almost working, but it crashes in mysterious ways.  I'm suspecting
that it's a problem with the atomic math or something to do with the threads.

When I look at it in CygWin's gdb, I always get a crash in the same place, but I
don't think I am seeing the code that is crashing.  Instead what I think is
going on is that some objects are destroyed as they go out of scope, and
reference counts are being decremented, and maybe even semaphores are released,
and so all kinds of stuff is going on that I don't see in gdb.

GDB has some support for threads, but it doesn't seem to be helping me.

One thing that I see happening is that if I set a breakpoint where an object is
declared on the stack, and step into its constructor and back out, my crash does
not happen.  This is part of what's making me think my problem is with thread
handling; I believe each time one steps gdb lets all the running threads
continue to run and then stops them.

I know this is kind of vague but can anyone give me any suggestions on how to
debug this?

I haven't done this but I understand single stepping through the assembly for
atomic arithmetic can screw it up.

Something helpful I found tonight is that I can disable the use of COM by
defining:

#define NOCOMATTRIBUTES

in the header file that ZooLib includes globally (zconfig.h).  If I didn't do
this, my compile would fail because I wasn't using -fvtable-thunks.  If I did
use -fvtable-thunks, my program jumps into outer space on the first virtual
function call because there is a binary incompatibility between my compiled code
and the runtime library.  The ultimate solution to this is to build the runtime
libraries with -fvtable-thunks on but I haven't figured out how to do that yet.

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.

Now if I could get this bug fixed I think it should work and I'd be really
stoked.

Mike
-- 
Michael D. Crawford
GoingWare Inc. - Expert Software Development and Consulting
http://www.goingware.com
crawford@goingware.com

  Tilting at Windmills for a Better Tomorrow.

--
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/