From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2519 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: STLport Date: Mon, 31 Dec 2012 10:29:56 -0500 Message-ID: <20121231152956.GM20323@brightrain.aerifal.cx> References: <1716568.15394.1356922853329.JavaMail.root@grantgray.id.au> <50E1319C.1060301@gmail.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1356967814 7490 80.91.229.3 (31 Dec 2012 15:30:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 31 Dec 2012 15:30:14 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2520-gllmg-musl=m.gmane.org@lists.openwall.com Mon Dec 31 16:30:30 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1TphJp-0001Lv-R3 for gllmg-musl@plane.gmane.org; Mon, 31 Dec 2012 16:30:26 +0100 Original-Received: (qmail 11595 invoked by uid 550); 31 Dec 2012 15:30:09 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 11587 invoked from network); 31 Dec 2012 15:30:09 -0000 Content-Disposition: inline In-Reply-To: <50E1319C.1060301@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2519 Archived-At: On Mon, Dec 31, 2012 at 12:33:00PM +0600, agent wrote: > >Is anyone already working on a libc++ integration with musl? > > > i have tried to build the whole stack: clang, libc++, libc++abi with > musl, though i got stuck with libunwind for libc++abi. libc++ > compiled fine when using libsupc++, but i didn't test it anyhow > (maybe it is even unusable). i'm going to try out clang + libc++ + > libcxxrt + musl soon.they say libc++ works with libcxxrt and > libcxxrt has it's own unwind. We seem to be _almost_ to the point of having libunwind working now. The only failure I'm still seeing is missing sigreturn/setcontext, which are referenced from src/x86/Gos-linux.c. Adding the full ucontext stuff would be a pain (lots of arch-specific code), but we could cheat and handle just setcontext with minimal code by letting the kernel do all the work (it requires a syscall anyway to set the signal mask, so we might as well let the kernel do all the work by implementing setcontext in terms of SYS_rt_sigreturn). With that said, I suspect the function in src/x86/Gos-linux.c that's using sigreturn and setcontext is utterly useless; its purpose seems to be unwinding across signal handler boundaries, which cannot happen in correct programs anyway. Replacing the whole function with something like *(volatile char *)0=0; (i.e. crash) should get you a working libunwind. Rich