From owner-freebsd-bugs@FreeBSD.ORG Tue Sep 14 11:20:03 2010 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC72E106564A for ; Tue, 14 Sep 2010 11:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 90B3A8FC18 for ; Tue, 14 Sep 2010 11:20:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o8EBK35W047697 for ; Tue, 14 Sep 2010 11:20:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o8EBK39v047696; Tue, 14 Sep 2010 11:20:03 GMT (envelope-from gnats) Date: Tue, 14 Sep 2010 11:20:03 GMT Message-Id: <201009141120.o8EBK39v047696@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Kostik Belousov Cc: Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kostik Belousov List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 11:20:03 -0000 The following reply was made to PR kern/131597; it has been noted by GNATS. From: Kostik Belousov To: David Xu Cc: John Baldwin , bug-followup@freebsd.org, guillaume@morinfr.org, kan@freebsd.org Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64 Date: Tue, 14 Sep 2010 14:12:12 +0300 --S7pq8suDAU0LBjBQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 14, 2010 at 02:00:13PM +0000, David Xu wrote: > John Baldwin wrote: >=20 > >Do we know of any use cases where libunwind would be used from a signal > >handler? Could we instead simply declare it to be an unsafe API in a=20 > >signal > >context? longjmp(3) isn't safe in a signal context and throwing excepti= ons > >in a signal handler is undefined, so declaring libunwind to similarly be > >unsafe may be fine. > > >=20 > It is true that libunwind would be used from a signal handler. > In fact, when I was working on stack unwinding support for libthr, I > found it. >=20 > The reason I was trying to do it is that I want to let C++'s on-stack > object to be destructed when thread is exited, otherwise, C++ program > can not use pthread cancellation feature, the pthread cancellation > calls pthread_exit(), and the function should unwind the thread's stack > for C++ like language, otherwise the programs leak resource. >=20 > In head branch, things are improved, for defer-mod, thread cancellation > is called from in-place context, but for asynchronous mode, thread > cancellation is called from a signal handler, the SIGCANCEL hanlder, so > the libunwind needs to dig out the saved context and unwind the > interrupted stack. >=20 > A very bad news is libunwind only did unwind-through-signal-stack for > linux, nothing has been done for FreeBSD and others, code has been > found here: > /usr/src/contrib/gcc/config/i386/linux-unwind.h Err ? When I ported libunwind, I spent a lot of time making unwind through the signal frame working. The part of the trouble was that our signal trampoline lacks unwind info. And annotating the trampoline is not a whole solution, since libunwind can only find the FDEs by =2Eeh_frame_hdr of some dso. This would require creating fake dso for trampolines. I decided to use old-linuxish method of unwinding by hardcoding frame format and trampoline code sequence for detection. >=20 > I even have a patch for FreeBSD x86 to support the > unwind-through-signal-stack, but I have not fully tested it. > http://people.freebsd.org/~davidxu/patch/unwind.patch > You can say this is a crazy idea, but they did it. >=20 > >>>OTOH, I'm not sure why libthr needs to use non-standard lock hooks at > >>>this point as they don't seem to be markedly different from the ones > >>>rtld uses. > >>libthr locks provide exclusion both for other kernel-executed threads > >>and signal handlers, while the rtld-default locks only protect against > >>signal handlers and thus libc_r-style threads. > > > >Oh, bah. The rtld locks do use atomic operations that are thread safe, > >but I missed that the 'oldsigmask' global needs to be per-thread. > > >=20 > In head branch, when program is linked with libthr, and created a > thread, the libthr's rtld lock implementation is activated, > performance should be improved, but otherwise, it is still slow for > non-threaded C++ program. BTW, the signal handler interposition that you implemented for libthr probably belongs to libc. I already implemented dso filtering for our rtld, so I hope to start discussion about merging libc and libthr into single library. Then libc could interpose signal handlers. --S7pq8suDAU0LBjBQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkyPWIsACgkQC3+MBN1Mb4jN7wCg0DrtBTWEhOzMQNr9+nTYnYFu l7kAoIBzrW8xguotia3aSj45Hr/2G4Kb =r1Ml -----END PGP SIGNATURE----- --S7pq8suDAU0LBjBQ--