[cfe-dev] libc++ in Windows

Nico Rieck nico.rieck at gmail.com
Wed Jun 26 07:35:59 PDT 2013


On 26.06.2013 02:57, Daniel Dilts wrote:
> When I was looking at libc++ it didn’t appear to support Windows except maybe under MinGW.  What would be a good place to start to get libc++ to work on Windows?

I've been working on this on and off. Here's a braindump of what's needed:

1. Port OS-specific things.

    This is rather small and I've done most of this already.

2. C Standard Library.

    Microsoft's CRT is a royal PITA. It doesn't support a lot of things
    required or expected, and other things have subtle differences.
    Which is why I wrote a new standard library to make point 1 easier.
    At first it was only a set of standard-compliant headers and
    implementation stubs to get it to compile, but I've since
    implemented certain parts. The hardest part for this route is, for
    me at least, libm, and I don't know any modern BSD-licensed libm
    that could be used.
    The other way would be to further try and shoehorn MSVCRT and give
    up C99- and full C++11-compatibility.

3. Implement full dllimport/dllexport semantics so that libc++ can be
    used as a DLL.

    Clang only support rudimentary dllimport/dllexport for functions.
    Making it work with classes is a rather large non-trivial change.
    I've been working on this and apart from vtable-handling and
    cleanups it's mostly finished. Depending on that last point I may
    put up some patches for review soon.

    This also requires changes to how libc++ applies those attributes.
    Using them like ELF visibility doesn't work correctly for templates.

4. Weak externals for PE to enable replacing operator new/delete.

    This was impossible with how dllimport was represented in LLVM
    before. If my patches are excepted, it should be doable, but I
    haven't looked into it again.

5. Port an ABI library like libc++abi.

    I've ported some parts of libc++abi, but it's incomplete and
    untested. It also needs an unwind library, which quickly leads
    to the next point:

6. Exception handling

    This is probably the biggest hurdle. There is some low-level support
    for 64-bit SEH directives in LLVM already. 32-bit has the additional
    Borland patent issue for SEH exception handling. The data structures
    used by MSVC are also undocumented.
    Implementing this for 64-bit by using the DWARF exception tables and
    providing an appropriate personality routine is the easiest case,
    and would also allow catching SEH exceptions from the OS.
    Maybe it's also possible to implement such DWARF-based table-based
    exception handling for 32-bit, without any way to catch SEH
    exceptions.

7. Some minor bugfixes I encountered along the way, like proper COMDAT
    linkage for EH sections, proper varargs handling. I'll try to get
    those committed soon.


-Nico



More information about the cfe-dev mailing list