[cfe-dev] libc++ in Windows

[Daniel Dilts]

>> 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.



It seems like you really have a handle on the work that is needed.  It also seems that you have a good start on much of it.


I am new to Clang, and relatively new to compilers.  I don’t suppose you could point out a smallish task or two that I could do in parallel with your efforts, could you?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130627/134c4b20/attachment.html>