From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 23 14:42:12 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 5F4CF1065673; Sun, 23 Jan 2011 14:42:12 +0000 (UTC) Date: Sun, 23 Jan 2011 14:42:12 +0000 From: Alexander Best To: Ryan Stone Message-ID: <20110123144212.GA32293@freebsd.org> References: <20110113190625.GA76352@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110113190625.GA76352@freebsd.org> Cc: FreeBSD Hackers Subject: Re: What does the FreeBSD/i386 ABI say about stack alignment? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 14:42:12 -0000 On Thu Jan 13 11, Alexander Best wrote: > On Thu Jan 13 11, Ryan Stone wrote: > > I've been trying to get an application compiled with gcc 4.5.1 running > > on FreeBSD 8.1, but it's been crashing during startup with a SIGBUS. > > It turns out that the problem is that gcc is issuing SSE > > instructions(in my case, a movdqa) that assume that the stack will be > > aligned to a 16-byte boundary. It seems that Linux/i386 guarantees > > this, and I worry that gcc has extended this assumption to all i386 > > architectures. I'm assuming that FreeBSD doesn't make any such > > promises based on the fact that I'm getting crashes. > > > > There does seem to be a flag (-mstackrealign) that you can set to > > force gcc to align the stack to what it wants, but that pessimizes the > > generated code a bit. Some googling would seem to indicate that > > -mpreferred-stack-boundary won't always handle this problem correctly. > > > > Any ideas? My inclination, at least for our local source tree here at > > $WORK, would be to accommodate gcc and guarantee the stack alignment > > that it wants rather than pessimize our application. It seems we have > > an old local patch/hack in our FreeBSD 6.1 tree(apparently based on > > this: http://www.freebsd.org/cgi/getmsg.cgi?fetch=438552+0+/usr/local/www/db/text/2000/freebsd-current/20000507.freebsd-current). > > I believe that this patch is the reason why we haven't seen the > > problem when running on 6.1, but the patch doesn't seem to work > > anymore on 8.1. > > i'm experiencing a similar issue on amd64 with mplayer (svn snapshot) and > gcc46: > > otaku% ./mplayer ~/filme/wiedhow.mkv > MPlayer SVN-r32787-4.6.0 (C) 2000-2011 MPlayer Team > 161 audio & 350 video codecs > > Playing /home/arundel/filme/wiedhow.mkv. > zsh: illegal hardware instruction (core dumped) ./mplayer ~/filme/wiedhow.mkv > otaku% echo $? > 132 just wanted to report that the issue i was having with mplayer vanished. so it seems this was in fact a bug in mplayer itself. cheers. alex > > i'm not sure however, if both matters are related. gdb and 'bt' report: > > #0 0x0000000805327f03 in sscanf (str=0xa
, fmt=0x7fffffbffe60
) at /usr/subversion-src/lib/libc/stdio/sscanf.c:46 > 46 { > [New Thread 80a407400 (LWP 105253/initial thread)] > (gdb) bt > #0 0x0000000805327f03 in sscanf (str=0xa
, fmt=0x7fffffbffe60
) at /usr/subversion-src/lib/libc/stdio/sscanf.c:46 > #1 0x000000000062fa25 in vsscanf () > #2 0x0000000805327f84 in sscanf (str=Variable "str" is not available. > ) at /usr/subversion-src/lib/libc/stdio/sscanf.c:51 > #3 0x000000000062fa25 in vsscanf () > > cheers. > alex > > -- > a13x -- a13x