Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.