From owner-freebsd-sparc64@FreeBSD.ORG Fri Nov 12 18:37:00 2010 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF7EB10656C4; Fri, 12 Nov 2010 18:37:00 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 1CCCE8FC17; Fri, 12 Nov 2010 18:36:59 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id oACIMUZM022041; Fri, 12 Nov 2010 19:22:30 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id oACIMTw1022040; Fri, 12 Nov 2010 19:22:29 +0100 (CET) (envelope-from marius) Date: Fri, 12 Nov 2010 19:22:29 +0100 From: Marius Strobl To: Florian Smeets Message-ID: <20101112182229.GA20533@alchemy.franken.de> References: <20101111155243.GL2054@hoeg.nl> <4CDD55D0.10004@smeets.im> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CDD55D0.10004@smeets.im> User-Agent: Mutt/1.4.2.3i Cc: Ed Schouten , sparc64@freebsd.org, current@freebsd.org, toolchain@freebsd.org Subject: Re: libcompiler_rt now part of FreeBSD's base system X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 18:37:00 -0000 On Fri, Nov 12, 2010 at 03:57:20PM +0100, Florian Smeets wrote: > On 11.11.10 16:52, Ed Schouten wrote: > > I just committed libcompiler_rt.a to HEAD. Even though I don't expect > > serious issues -- especially not on the tier 1 architectures -- be sure > > to contact me in case something goes wrong. I hooked it up to the build > > in a separate commit, so if your system starts to act weird, just revert > > r215127. > > > > Hi Ed, > > i'm at r215149 on sparc64, and my compiler stopped working. buildworld > stops after 42 lines (http://smeets.im/~flo/bw.log). cc1 dumps a 1GB > core file. > > Program terminated with signal 4, Illegal instruction. > #0 0x00000000004ced80 in ?? () > (gdb) where > #0 0x00000000004ced80 in ?? () > #1 0x00000000004cedb0 in ?? () > Previous frame identical to this frame (corrupt stack?) > > Right now i cannot go back to r215126 to verify that it really is this > change which is causing it :-) Previously the system was running a build > from around Nov. 1st > I was just about to report the same based on a test of r214838. With debugging symbols I get a more meaningful though: nimrod# gdb /tmp/objrt.old/usr/home/marius/co/compiler-rt/gnu/usr.bin/cc/cc1/cc1 /tmp/objrt/usr/home/marius/co/compiler-rt/tmp/usr/home/marius/co/compiler-rt/tools/build/cc1.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc64-marcel-freebsd"...(no debugging symbols found)... Core was generated by `cc1'. Program terminated with signal 4, Illegal instruction. #0 0x00000000004c0aa0 in __ctzdi2 () (gdb) bt #0 0x00000000004c0aa0 in __ctzdi2 () #1 0x00000000004c0ad0 in __ctzdi2 () (gdb) The corresponding assembler code is: 00000000004c0aa0 <__ctzdi2>: 4c0aa0: 9d e3 bf 40 save %sp, -192, %sp 4c0aa4: 82 10 00 18 mov %i0, %g1 4c0aa8: 80 a0 00 18 cmp %g0, %i0 4c0aac: 85 3e 30 20 srax %i0, 0x20, %g2 4c0ab0: b0 40 3f ff addc %g0, -1, %i0 4c0ab4: 90 38 00 18 xnor %g0, %i0, %o0 4c0ab8: 84 0e 00 02 and %i0, %g2, %g2 4c0abc: 90 0a 00 01 and %o0, %g1, %o0 4c0ac0: b0 0e 20 20 and %i0, 0x20, %i0 4c0ac4: 90 12 00 02 or %o0, %g2, %o0 4c0ac8: 7f ff ff f6 call 4c0aa0 <__ctzdi2> 4c0acc: 91 32 20 00 srl %o0, 0, %o0 4c0ad0: b0 06 00 08 add %i0, %o0, %i0 4c0ad4: 81 cf e0 08 rett %i7 + 8 4c0ad8: 91 3a 20 00 sra %o0, 0, %o0 4c0adc: 01 00 00 00 nop I think what happens here is that GCC uses __ctzdi2() to implement __builtin_ctz(), while the libcompiler-rt version of __ctzdi2() uses __builtin_ctz(), so __ctzdi2() is called recursively until the stack overflows. Note that GCC has code like: int __ctzsi2 (uSI x) { return __builtin_ctz (x); } and rwindow_save() returns SIGILL, so I think this theory is correct but I've no idea how to solve that. Another thing that worries me is that by switching to libcompiler-rt we lose all the assembler optimizations libgcc has for sparc64. When building with libcompiler-rt the buildworld time increases by 2.6% on sparc64. I guess this mostly is due to the fact that now both libcompiler-rt and libgcc are built though. Do you have an idea how to benchmark the possible performance loss with libcompiler-rt for typical applications? Marius