compiling wineserver under cygwin - thread context
davidf at sjsoft.com
Thu Nov 28 08:51:37 CST 2002
David Fraser wrote:
> The significant compilation problem is in server/context_i386.c: You
> must implement get/set_thread_context for your platform.
> Basically there's some code that does the threading stuff which is
> platform-specific. There are Linux and BSD and Sun variants, none of
> which work under cygwin ... Basically sys/ptrace.h is what's missing.
> This lets the process interrupt a child process and get/set its
> registers. Does anyone have any idea what the best way to write a
> replacement for cygwin would be? Maybe I need to ask the cygwin list.
After some more investigating ... Dimi added a request for ptrace
support in cygwin in November 2000:
But I can't see anything that's been done about it. So I thought I would
clarify here exactly what should
be done before trying to do it...
The platform-specific bits define the functions get_thread_context and
which each use ptrace (in the existing platforms) to get / set registers
for that thread.
The requests given to ptrace are:
PTRACE_PEEKUSER / PTRACE_POKEUSER (for getting / setting debugging
PTRACE_GETREGS / PTRACE_SETREGS (for getting / setting general registers)
PTRACE_GETFPREGS (for getting / setting floating point registers)
so it's fairly simple...
As far as I can see the only places get_thread_context and
set_thread_context are used is in
scheduler/thread.c, to implement WINAPI GetThreadContext and
Now from reading through the sources Wine uses clone() to create
threads, using its own implementation
of clone for linux if not available that looks like it wouldn't work
Cygwin has a pthreads implementation that maps onto the Windows Thread
So part of the question is, in order to get Wine to function properly on
Cygwin, what is the right
threading approach to take? Am I right in thinking that the current code
wouldn't work on Cygwin?
Approach 1 would be to simply call the Windows Thread functions from
Wine if compiled on Cygwin
That would involve the nastiness of including the w32api headers...
Approach 2 would be to just use the Windows
since they're just looking at registers etc. These could then be wrapped
up in an (incomplete) ptrace
implementation for cygwin, which we would call.
Approach 3 would be to reimplement the appropriate parts of ptrace for
cygwin in some other way.
I'm guessing Approach 2 is right.
Anyway any advice would be appreciated
More information about the wine-devel