Date: Mon, 31 Dec 2012 10:29:56 -0500 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: STLport 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.