The following reply was made to PR kern/131597; it has been noted by GNATS.
From: Kostik Belousov <kostik...@gmail.com>
To: David Xu <davi...@freebsd.org>
Cc: John Baldwin <j...@freebsd.org>, bug-follo...@freebsd.org,
guilla...@morinfr.org, k...@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--
_______________________________________________
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
