From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19879 invoked by alias); 5 Oct 2008 14:47:47 -0000 Received: (qmail 19868 invoked by uid 22791); 5 Oct 2008 14:47:46 -0000 X-Spam-Check-By: sourceware.org Received: from smtp6-g19.free.fr (HELO smtp6-g19.free.fr) (212.27.42.36) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 05 Oct 2008 14:46:51 +0000 Received: from smtp6-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp6-g19.free.fr (Postfix) with ESMTP id D89BE1725C for ; Sun, 5 Oct 2008 16:46:48 +0200 (CEST) Received: from [192.168.0.2] (gre92-6-82-231-206-104.fbx.proxad.net [82.231.206.104]) by smtp6-g19.free.fr (Postfix) with ESMTP id 680C617273 for ; Sun, 5 Oct 2008 16:46:47 +0200 (CEST) Message-ID: <48E8D34F.4@yahoo.fr> Date: Sun, 05 Oct 2008 14:47:00 -0000 From: =?ISO-8859-1?Q?S=E9bastien_Kunz-Jacques?= User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: pthreads-win32@sourceware.org Subject: Re: pthreads-win32 2.8.0, stack alignment, and SSE code References: <48E8B399.502@yahoo.fr> <48E8C3B8.2080709@lisha.ufsc.br> In-Reply-To: <48E8C3B8.2080709@lisha.ufsc.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes Mailing-List: contact pthreads-win32-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: pthreads-win32-owner@sourceware.org X-SW-Source: 2008/txt/msg00055.txt.bz2 Ramiro Polla a écrit : > Sébastien Kunz-Jacques wrote: >> Hi, >> >> I encountered problems with SSE code compiled with recent mingw GCC >> (4.3.2, TDM release, http://www.tdragon.net/recentgcc/) and using >> pthreads 2.8.0. After inverstigation, crashes occured because the >> code was trying to read operands on the stack, assuming the stack was >> 16-byte aligned as is the case in the main thread (the main function >> aligns the stack and alignment is maintained during each function >> call). I solved the issue with a very simple patch that uses some >> GCC wizardry to force stack realignment upon entry in a new thread: >> >> --- ptw32_threadStart.c Sun May 15 17:28:27 2005 >> +++ ptw32_threadStart.c Mon Sep 29 21:28:16 2008 >> @@ -116,6 +116,9 @@ >> >> #endif >> >> +#if defined(__GNUC__) && (__GNUC__ > 4 || __GNUC__ == 4 && >> __GNUC_MINOR__>1) >> +__attribute__((force_align_arg_pointer)) >> +#endif >> #if ! defined (__MINGW32__) || (defined (__MSVCRT__) && ! defined >> (__DMC__)) >> unsigned >> __stdcall >> >> >> The attribute force_align_arg_pointer should be added to every >> function that is called with a stack with insufficient alignment; as >> far as I am concerned doing this for threadStart only solved my >> problems. Maybe this small patch could be added to the pthread code? > > I think that's related to: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216 > > So I think this patch shouldn't be applied to pthreads-win32, and > people should rather use another version of MinGW (or unset automatic > SSE code, if that makes any sense). > > Ramiro Polla > Not at all ; I use a modified binutils that enforces 16-byte alignment alignment of .bss sections (basically I reverted the part of the binutils patch that is linked to in the gcc bug 37216 thread). The bug I experienced shows up only in threaded code and comes from the fact that a stack of a win32 thread in only 4-byte aligned. The crash occurs when a data is read on the stack and not in a .bss segment. To give some contextual information, I tried to build a math library, ATLAS, with mingw. First, for the non-threaded version, I encountered bug 37216 that you mention ; to get rid of this I patched binutils (adding -fno-common to gcc works also). But the threaded version was still crashing, and indeed the symptoms looked much similiar to what occurred in the non-threaded case. Then I found the solution evoked in my first post. Please note that adding the attribute force_align_arg_pointer to threadStart has a negligible performance penalty (a few machine instructions each time this function is entered/exited)