Re: libcompiler_rt now part of FreeBSD's base system

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