On Sun, 26 Mar 2000, Ulrich Weigand wrote:
>
> In any case, I know of at least one pthread implementation under Solaris/x86
> that definitely does use %gs (because due to a kernel bug not only Wine
> crashes when the %gs descriptor is overwritten by Wine, but even the
> kernel panics :-/) ...
>
Like Patrick's stdcall thunking, we should choose whether or not we need
to save %gs at compile time, then arrange for tools/build to generate the
appropriate thunks. If we want to be really clever, we can compile
multiple different versions in and choose one at runtime without any
(additional, i.e. over the cost of the thunk) performance penalty.
> > (If %gs ever comes back, maybe we can convince Drepper to put hooks into
> > linuxthreads for us to use. They have a function called thread_self that
> > returns a pointer to their thread data structure. We could replace that
> > function and just keep their data in our TEB somewhere.)
>
> Unfortunately, thread_self is inlined for efficiency reasons (same as our
> get_teb b.t.w.). One option might be to compile a special version of
> linuxthreads for use with Wine only ... On the other hand, one benefit
> of using POSIX threads would be portability :-/ [ There's a whole bunch of
> other things that are really Linux-specific anyway, even if we were to use
> linuxthreads; foremost the assumption (by the server) that every thread
> has its own pid and can be sent signals independently. ]
>
If you want to send a signal to a specific thread, use pthread_kill. This
can only be done from another thread, so we could dedicate a thread to
dispatching signals from the wineserver to wine threads.
The big assumption is that we can ptrace each thread. Otherwise, we are
stuck with using pthread_join to look for threads that have exited.
> Ah, right. This is something I forgot: while in a signal handler, we
> are not on the correct thread stack, and thus the LinuxThreads thread_self
> will fail (if the %gs method is not active). This means that we cannot
> use pthread routines (and by extension, many libc routines) unless we
> fix this problem (e.g. by making the per-thread signal stack part of the
> address space reserved for the per-thread standard stack as passed to
> pthread).
>
I did exactly that. The signal and regular stacks are allocated
contiguously, and pthreads is told about the whole range.
> As to SEH: the SEH unwind *itself* doesn't longjmp, but the app-provided
> handler routine called by it will typically do so. In fact, our own
> WINE_exception_handler, which is used by WineLib apps and the Wine core
> itself, explicitly uses longjmp, and when running Win32 apps, the handler
> provided by the MS C compilers does something equivalent (without actually
> returning to Wine code IIRC).
>
> While we can modify the Wine handler, the app-provided handlers must work
> as well, so we'd have to find a way that allows signal handlers that don't
> properly return ...
>
I think it's a non issue. Originally I thought that getting a signal and
longjmping repeatedly out would eventually exhaust the kernel stack. Silly
me. linuxthreads keeps track of when we are in a signal handler, but it
seems to only use that for an optimisation. The only other catch is that
if somebody calls CreateThread while on the signal stack, the child will
inherit the signal stack and although it turns it off ASAP, we will have
trouble if a signal comes in first.
Andrew Lewycky
[EMAIL PROTECTED]
