[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Activating -debug for winelib applications
From:       Albert den Haan <uz87ogw3 () umail ! furryterror ! org>
Date:       1999-05-31 19:38:04
[Download RAW message or body]

With the recent re-organization of the Wine processes and threads we
seem to have lost the ability to use debugger-of-choice to check what is
happening inside our natively compiled applications.

I have traced things through enough to see where the
process/thread/whatever we want to trace is forked off the parent thread
and now wonder if my 'simple' idea is good enough for the moment.

My idea is this.  Use the '-debug' command line option that winelib apps
currently ignore to guard some code at the start of the application
thread that: dumps the process id to stderr, and uses the SIGSTOP signal
to wait for a debugger to attach to the thread.  With this in place a
savvy user can hook up a debugger to the application with minimal
hassle.

But, based on the current pthread discussion and other process problems
discussed lately I wonder if this will work.  

So I have a few questions:
* Are threads that gdb understands bad for libwine apps or just apps run
under the emulator?
* could the libwine process structure be re-organized a bit to make
debugging easier without munging things up too much?
* Is there any solid documentation of the what and why of the various
process/thread structures somewhere?  Where do I start reverse
engineering it if there isn't?
	
	Albert.

--
Albert den Haan @ Linux Port Team . Corel Corporation
albertd@corel.ca


=========================================================================

[prev in list] [next in list] [prev in thread] [next in thread]