Re: [PATCH] ntdll: The FPU control word for newly created threads is 0x27f.
Henri Verbeet <hverbeet(a)codeweavers.com> writes:
diff --git a/dlls/ntdll/thread.c b/dlls/ntdll/thread.c index 36f1499..0d383bd 100644 --- a/dlls/ntdll/thread.c +++ b/dlls/ntdll/thread.c @@ -384,6 +384,7 @@ static void start_thread( struct startup_info *info ) thread_data->pthread_id = pthread_self();
signal_init_thread( teb ); + signal_init_thread_fpu(); server_init_thread( func ); pthread_sigmask( SIG_UNBLOCK, &server_block_set, NULL );
This should be done inside signal_init_thread(), that's already meant for platform-specific setup, there's no need to add a separate entry point. Also you may want to do an fninit if new threads are not supposed to inherit FPU state. -- Alexandre Julliard julliard(a)winehq.org
On 16 June 2010 19:36, Alexandre Julliard <julliard(a)winehq.org> wrote:
This should be done inside signal_init_thread(), that's already meant for platform-specific setup, there's no need to add a separate entry point. That was the original plan, but signal_init_thread() is also called by thread_init().
Henri Verbeet <hverbeet(a)gmail.com> writes:
On 16 June 2010 19:36, Alexandre Julliard <julliard(a)winehq.org> wrote:
This should be done inside signal_init_thread(), that's already meant for platform-specific setup, there's no need to add a separate entry point. That was the original plan, but signal_init_thread() is also called by thread_init().
You have to handle that anyway. If you add a generic init_thread_fpu() entry point it has to be called for all threads too, otherwise it's not really generic. The initial thread can be detected for instance by checking if the process heap exists. -- Alexandre Julliard julliard(a)winehq.org
participants (2)
-
Alexandre Julliard -
Henri Verbeet