Re: libcompiler_rt now part of FreeBSD's base system [SEC=UNCLASSIFIED]
On Fri, Nov 12, 2010 at 5:24 AM, Wilkinson, Alex wrote: > > 0n Thu, Nov 11, 2010 at 04:52:43PM +0100, 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 > >r2151 > Can you please explain to us what this actually brings to the table for > freebsd ? > I know it replaces libgcc ... but why is that such a good thing ? > > -Alex The main thing is that it's BSD-licensed instead of GPL, I believe. -- Daniel Nebdal ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
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 0x004ced80 in ?? () > (gdb) where > #0 0x004ced80 in ?? () > #1 0x004cedb0 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 0x004c0aa0 in __ctzdi2 () (gdb) bt #0 0x004c0aa0 in __ctzdi2 () #1 0x004c0ad0 in __ctzdi2 () (gdb) The corresponding assembler code is: 004c0aa0 <__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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: libcompiler_rt now part of FreeBSD's base system
On Nov 11, 2010, at 7:52 AM, Ed Schouten wrote: > Hello all, > > 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. I'm testing ia64, right now. I see the following: pluto2# chroot /tank/release/current /bin/tcsh # cd /lib # ls -al *gcc* *compiler* -r--r--r-- 1 0 0 104952 Nov 12 15:55 libgcc_s.so.1 # cd /usr/lib # ls -al *gcc* *compiler* -r--r--r-- 1 0 0 172434 Nov 12 15:53 libcompiler_rt.a -r--r--r-- 1 0 0 209196 Nov 12 15:53 libcompiler_rt_p.a lrwxr-xr-x 1 0 0 16 Nov 12 15:53 libgcc.a -> libcompiler_rt.a -r--r--r-- 1 0 0 60754 Nov 12 15:55 libgcc_eh.a -r--r--r-- 1 0 0 65706 Nov 12 15:55 libgcc_eh_p.a lrwxr-xr-x 1 0 0 18 Nov 12 15:53 libgcc_p.a -> libcompiler_rt_p.a lrwxr-xr-x 1 0 0 18 Nov 12 15:55 libgcc_s.so -> /lib/libgcc_s.so.1 This looks like an inconsistency to me. Aren't we building a shared libcompiler_rt to replace the shared libgcc? Should I worry about the EH support? BTW: The chroot seems functional from the minimal testing I've done so far. We're not DOA! :-) -- Marcel Moolenaar xcl...@mac.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: libcompiler_rt now part of FreeBSD's base system
Florian, others, * Florian Smeets , 20101112 15:57: > 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. I'll look into as soon as possible, but to prevent additional breakage, I've switched sparc64 back to the original libgcc. -- Ed Schouten WWW: http://80386.nl/ pgp1COBdVlSe2.pgp Description: PGP signature
Re: libcompiler_rt now part of FreeBSD's base system
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 0x004ced80 in ?? () (gdb) where #0 0x004ced80 in ?? () #1 0x004cedb0 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 Anything i can do to narrow this down? -- Florian Smeets ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: libcompiler_rt now part of FreeBSD's base system [SEC=UNCLASSIFIED]
0n Thu, Nov 11, 2010 at 04:52:43PM +0100, 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. Can you please explain to us what this actually brings to the table for freebsd ? I know it replaces libgcc ... but why is that such a good thing ? -Alex IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: libcompiler_rt now part of FreeBSD's base system
On Thu, Nov 11, 2010 at 04:52:43PM +0100, Ed Schouten wrote: > Hello all, > > 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. great! can you share some more info about: -what is the plan for the unwinder etc? I know there's something from apple (not opensourced yet?) and others (tm) (not announced publicly yet I think) -how often(ever?) do you plan to update? while there's not much going on in compiler-rt repo it's not dead -do you plan to tackle libc++ now? :-P roman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: libcompiler_rt now part of FreeBSD's base system
On Thu, Nov 11, 2010 at 04:52:43PM +0100, Ed Schouten wrote: > Hello all, > > 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. > > Thanks to everyone who helped testing this! > Perhaps, a note in src/UPDATING to record the revision number and the __FreeBSD_version is merited. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
libcompiler_rt now part of FreeBSD's base system
Hello all, 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. Thanks to everyone who helped testing this! -- Ed Schouten WWW: http://80386.nl/ - Forwarded message from Ed Schouten - > Date: Thu, 11 Nov 2010 15:48:27 + (UTC) > From: Ed Schouten > To: src-committ...@freebsd.org, svn-src-...@freebsd.org, > svn-src-h...@freebsd.org > Subject: svn commit: r215127 - in head: . gnu/lib/libgcc lib sys/sys > > Author: ed > Date: Thu Nov 11 15:48:27 2010 > New Revision: 215127 > URL: http://svn.freebsd.org/changeset/base/215127 > > Log: > Replace libgcc.a by libcompiler_rt.a. > > libcompiler_rt.a is a BSD licensed C language runtime, which implements > many routines which are linked into binaries on architectures where > certain functionality is missing (e.g. 64 bits mul/div on i386). > > Unfortunately, libcompiler_rt cannot replace libgcc entirely. Certain > features, such as an unwinder for exception handling, are missing. > That's why only libgcc.a is replaced for now, because this one does seem > to be complete. > > Tested by: rene (amd64), nwhitehorn (powerpc), droso (i386 exprun) > and many others. Thanks! > Obtained from: user/ed/compiler-rt > > - End forwarded message - pgpFfnvWsty91.pgp Description: PGP signature