From owner-freebsd-current@FreeBSD.ORG Wed Jul 4 14:33:19 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DEBAC1065670 for ; Wed, 4 Jul 2012 14:33:19 +0000 (UTC) (envelope-from taku@tackymt.homeip.net) Received: from basalt.tackymt.homeip.net (unknown [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by mx1.freebsd.org (Postfix) with ESMTP id 85E2D8FC0A for ; Wed, 4 Jul 2012 14:33:19 +0000 (UTC) Received: from basalt.tackymt.homeip.net (localhost [127.0.0.1]) by basalt.tackymt.homeip.net (Postfix) with ESMTP id 7531983A0 for ; Wed, 4 Jul 2012 23:33:18 +0900 (JST) X-Virus-Scanned: amavisd-new at tackymt.homeip.net Received: from localhost by basalt.tackymt.homeip.net (amavisd-new, unix socket) with ESMTP id QxsuUorDNGPl for ; Wed, 4 Jul 2012 23:33:17 +0900 (JST) Received: from basalt.tackymt.homeip.net (basalt.tackymt.homeip.net [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by basalt.tackymt.homeip.net (Postfix) with ESMTPSA for ; Wed, 4 Jul 2012 23:33:17 +0900 (JST) Date: Wed, 4 Jul 2012 23:33:16 +0900 From: Taku YAMAMOTO To: freebsd-current@freebsd.org Message-Id: <20120704233316.70ec8654.taku@tackymt.homeip.net> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.24.6; i386-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: FYI: SIGBUS with world built by clang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 14:33:20 -0000 For people having SIGBUS with clang-build world + gcc-build binaries, In short words, for any libraries (and never forget about rtld-elf!) which are potentially called from arbitrary binaries, compile them with either -mstackrealign or -mstack-alignment=8! The detail is as follows. I've observed that clang carelessly expects the stack being aligned at 16 byte boundary. For example, the following code: #include #include int foo(const char *format,...) { int ret; va_list ap; FILE f = {}; va_start(ap, format); ret = vfprintf(&f, format, ap); va_end(ap); return ret; } which turns into: pushl %ebp movl %esp, %ebp subl $264, %esp # imm = 0x108 xorps %xmm0, %xmm0 movaps %xmm0, -40(%ebp) movaps %xmm0, -56(%ebp) (snip; lots of movaps insns follows) which results in SIGBUS if %esp - 4 is not at 16 byte boundary. (Note: movaps expects the address aligned to 16 bytes!) This problem becomes visible when such functions get called from binaries compiled with other compilers which don't care about stack alignment. If the above code is compiled by clang with -mstackrealign: pushl %ebp movl %esp, %ebp andl $-16, %esp subl $272, %esp # imm = 0x110 xorps %xmm0, %xmm0 movaps %xmm0, 224(%esp) movaps %xmm0, 208(%esp) (snip; lots of movaps insns follows) it tries to align the stack prior to allocating local variables thus no problem. If the above code is compiled by clang with -mstack-alignment=8: pushl %ebp movl %esp, %ebp pushl %esi subl $252, %esp leal -240(%ebp), %esi movl %esi, (%esp) movl $232, 8(%esp) movl $0, 4(%esp) calll memset (snip) it calls memset instead of a bunch of movaps to clear the storage thus no problem, of course. # I don't know why clang doesn't utilize rep stosl, though. Pros and cons: -mstackrealign Pros: no function calls to memset probably faster because of SSE Cons: use of SSE means the need of saving FP registers potentially more stack consumption -mstack-alignment=# Pros: normal and predictive stack consumption don't spill SSE registers; no extra overhead on context switching Cons: depends on memset -- -|-__ YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. -