David Fraser wrote:
The significant compilation problem is in server/context_i386.c: You must implement get/set_thread_context for your platform.After some more investigating ... Dimi added a request for ptrace support in cygwin in November 2000:
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.
http://cygwin.com//cgi-bin/cygwin-todo.cgi?20001120.094813
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 set_thread_context
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 registers)
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 SetThreadContext
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 with cygwin...
Cygwin has a pthreads implementation that maps onto the Windows Thread functions.
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 GetThreadContext/SetThreadContext functions,
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
David
