Re: GCC withdraw
On 8/24/13 7:19 PM, David Chisnall wrote: On 24 Aug 2013, at 11:30, Sam Fourman Jr. sfour...@gmail.com wrote: So I vote, let's not give ourselves the burden of lugging dead weight in base for another 5 years. (in 2017 do we still want to be worrying about gcc in base?) Perhaps more to the point, in 2017 do we want to be responsible for maintaining a fork of a 2007 release of gcc and libstdc++? The same work needs to be done no matter where it is.. there is no saving in moving it, and a lot of hassle.. leave the damned thing alone and be thankful that we have switched to clang by default! don't over-reach your successes. David ___ freebsd-curr...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
On 8/23/13 6:35 PM, David Chisnall wrote: On 23 Aug 2013, at 10:58, Bernhard Fröhlich de...@freebsd.org wrote: I don't know if you are aware that IF you really do that we will have serious problems to ship packages for 10. USE_GCC=any is the fallback in the portstree for all ports that are unable to build with clang which was introduced when HEAD switched to clang as default cc. Right now there are 150 ports in the tree that use this fallback and quite a few of them are high profile ports: the highlights: audio/nas devel/mingw32-binutils emulators/qemu emulators/virtualbox-ose emulators/wine lang/go lang/v8 mail/courier math/fftw3 multimedia/libxine multimedia/gstreamer multimedia/gstreamer-plugins multimedia/x264 security/clamav the full list: http://dpaste.com/1354075/ A possible hack could be to add a check for USE_GCC=any to behave like a USE_GCC=yes on HEAD on the affected platforms. This pulls in lang/gcc from ports for a lot of people on HEAD I suppose. We certainly need to do that switch to remove the ancient gcc from base some time but with my portmgr hat on I can only say we don't plan to do that before 10.0 especially not if we are only talking about a few weeks time window. That is unfortunate. We have said for over a year that 10.0 should not ship with gcc. I can delay committing the patch to flip the switch until later in the code slush, if re approves, but ports that require gcc should be building with gcc from ports (which will also improve code quality, as gcc 4.6/7 produce significantly better code than 4.2.1). no, I believe we have said that 10 would ship with clang by default. NO mention was made about gcc being absent, and I am uncomfortable with taking that step yet. Having gcc just present, will not hurt you.. even after it is gone we will need to support those who will be replacing clang with newer versions of gcc in hteir own products. David ___ freebsd-curr...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
On 8/23/13 8:26 PM, Andriy Gapon wrote: on 23/08/2013 14:06 David Chisnall said the following: Our gcc is from 2007. It has no C11, no C++11 support. It has bugs in its atomic generation so you can't use it sensibly without lots of inline assembly (which it doesn't support for newer architectures) for multithreaded things. Our libstdc++ is ancient and doesn't work with modern C++ codebases. On the other hand these tools are perfect for building FreeBSD kernel and base. Extrapolating my experience with base GCC I am very confident in it as a FreeBSD development tool. Extrapolating my experience with Clang I am not yet confident in it as a FreeBSD development tool. I do not care about C11, C++11 and modern C++ codebases. I care about what's in /usr/src and what gets compiled by buildkernel/buildworld. That's just me, of course. But, OTOH, those who care modern C++ codebases should be perfectly capable to install a compiler from ports or switch to clang as their default compiler. +1 I'd like to see it still be there if you need it in 10 in 11 it's in ports ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: GCC withdraw
On 8/23/13 7:55 PM, Poul-Henning Kamp wrote: In message 52174d51.2050...@digsys.bg, Daniel Kalchev writes: - 9.x gcc default and clang in base; - 10.x clang default and gcc in ports; I believe this is the best idea so far. As long as these ports work with gcc in ports, that is. +1 well as I was forced to go back to gcc to get a compiling running kernel on my VPS (xen) I'm not convinced that clang is there yet. I'd be really grumpy if I had to go through al the ports hoopla to recompile my kernel. ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Fast sigblock (AKA rtld speedup)
On 1/11/13 9:31 PM, Konstantin Belousov wrote: On Sat, Jan 12, 2013 at 12:29:06AM +0100, Jilles Tjoelker wrote: On Fri, Jan 11, 2013 at 10:49:38PM +0200, Konstantin Belousov wrote: http://people.freebsd.org/~kib/misc/rtld-sigblock.3.patch The new fields td_sigblock_ptr and td_sigblock_val are in the part that is zeroed for new threads, while the code in rtld appears to expect them to be copied (on fork, vfork and pthread_create). The fields are correctly zeroed on exec. Thank you for noting this. Should be fixed in http://people.freebsd.org/~kib/misc/rtld-sigblock.4.patch Sharing the magic variable between threads means that one thread holding an rtld lock will block signals for all other threads as well. This is different from how the normal signal mask works but I don't know whether it may break things. However, the patch depends on it in some way because sigtd() does not know about fast sigblock and will therefore happily select a thread that is fast-sigblocking to handle a signal directed at the process. Hm, I do not quite follow, at least not the first part of the paragraph. The fast sigblock pointer is per-thread, so it is not shared in the kernel. Regardless of the kernel side, rtld is only supposed to use the fast block in the default implementation of the rtld locks, which are overriden by the libthr implementation on libthr initialization. There is also an explicit hand-off from the default locks to the external (libthr), and rtld cares to turn off fast sigblock mechanism when the handoff is performed. I assume that the thread notifies the kernel of the location.. Might I suggest as a saftybelt that on notification of this address that the kernel requires that a known magic value be in this location as proof that all is as expected.? just a thought. The selection of the thread for the delivery of signal in the mt process should not matter then, due to the mechanism not supposed to be used in the mt process. Although libthr's postpone approach is somewhat ugly, it does not depend on any non-standard kernel features and does not delay the default action. Would it be possible to move that code to libc to make things easier for rtld? It looks like this requires teaching libc about various threading concepts, though. The concern there is that rtld would need to have a tight coupling with libc, and possibly with libthr too. Something feels ugly about not allowing applications to use this, although I don't know how it would work. On the other hand, the strange signal state created by this and implicit assumptions that the duration will be short may be a reason to restrict its use to a relatively small piece of code. Application use of the interface is equivalent to the application willingly corrupt its own state. ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Fast sigblock (AKA rtld speedup)
On 1/7/13 10:22 AM, Konstantin Belousov wrote: Below is the forward of the patch for which I failed to obtain a private review. Might be, the list generates more responses. Our rtld has a performance bootleneck, typically exposed by the images with the lot of the run-time relocation processing, and by the C++ exception handling. We block the signals delivery during the rtld performing the relocations, as well as for the dl_iterate_phdr(3) (the later is used for finding the dwarf unwinding tables). The signal blocking is needed to allow the rtld to resolve the symbols for the signal handlers in the safe way, but also causes 2 syscalls overhead per each rtld entry. The proposed approach allows to shave off those two syscalls, doubling the FreeBSD performance for the (silly) throw/catch C++ microbenchmark. Date: Mon, 13 Aug 2012 15:26:00 +0300 From: Konstantin Belousov kostik...@gmail.com ... The basic idea is to implement sigprocmask() as single write into usermode address. If kernel needs to calculate the signal mask for current thread, it takes into the consideration non-zero value of the word at the agreed address. Also, usermode is informed about signals which were put on hold due to fast sigblock active. As I said, on my measurements in microbenchmark that did throw/catch in a loop, I see equal user and system time spent for unpatched system, and same user time with zero system time on patched system. Patch can be improved further, e.g. it would be nice to allow rtld to fall back to sigprocmask(2) if kernel does not support fast sigblock, to prevent flag day. Also, the mask enforced by fast sigblock can be made configurable. Note that libthr already blocks signals by catching them, and not using rtld service in the first line handler. I tried to make the change in the spirit of libthr interceptors, but handoff to libthr appears too complicated to work. In fact, libthr can be changed to start using fast sigblock instead of wrapping sigaction, but this is out of scope of the proposal right now. Is there any danger that an upriveliged user program can trick the kernel into doing anything it shouldn't by manipulating either the agreed upon address or the contents of the mask at the address? (even reading something by seeing what sigs get masked) This was an issue with the M:N threading package and resulted in extra syscalls to get around the problem. (I forget the details). ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
