Initial support for building libcxx/libcxxabi on MOS.

[asiekierka]

Starting point for #198 ; part of #233 ; probably resolves llvm-mos/llvm-mos-sdk#52 though may need more adaptation work with time.

$ mkdir build-libcxx
$ cd build-libcxx
$ cmake -G Ninja -C ../clang/cmake/caches/MOSLibCXX.cmake -S ../runtimes

llvm-mos-sdk must be in PATH - I make use of mos-sim-clang++ as a way to get the C++ code down to LLVM IR, as well as to provide the C standard library.

Requires llvm-mos/llvm-mos-sdk#128 - but it can be merged separately.

Proof of concept; I focused on getting it to compile only, though hello-new.cc seems to work (albeit with heap_limit etc. needing to be replaced by __heap_limit etc. - I assume libcxx's C stdlib wrappers break that approach).

Above all, I'd like to hear your feedback; as well as consider how to best integrate this into llvm-mos-sdk's build process.

[mysterymath]

The first thing that immediately comes to mind is how to test this; libcxx comes with a pretty extensive test suite, and we should probably try to get as much of it working as we can, otherwise we're never going to have any idea whether this stuff actually functions properly.

Like the end-to-end test suite, this will probably involve hooking it up to our simulator target and using a test runner. We'll also have go to through and scrub out anything float-related; I presume you've already done so, since this compiles, but there may be tests for this stuff that casually relies on floats.

Along those lines, building might be a bit of a strong term here; especially if this was done with mos-sim-clang, since that defaults to output IR. Nothing will actually complain if the backend can't lower that to 6502 assembly; I suspect that may be the case for quite a lot of this.

[asiekierka]

Like the end-to-end test suite, this will probably involve hooking it up to our simulator target and using a test runner.

Probably. There's more concerns though - I expect a lot of the test binaries to not fit in the 64K address space at all. C++ in a complete STL sense is, in my opinion, not suitable for a target like this, but...

We'll also have go to through and scrub out anything float-related

I've only scrubbed it out insofar as it prevented compilation, so not very much; my main focus with getting a larger C++ library going was to allow the compile-time powers of C++, which don't rely on the machine backend as much, and can make use of floats as well if one is careful.

Nothing will actually complain if the backend can't lower that to 6502 assembly; I suspect that may be the case for quite a lot of this.

Probably. I meant "building libcxx/libcxxabi" in a very literal sense.

[mysterymath]

Let's call these TODO(llvm-mos); otherwise it will be more difficult to find them again. Consider filing issues for these too; that will make them easier to track.

[mysterymath]

Is there something specific that makes remove different than all the other functions here? It seems odd to introduce a _LIBCPP_HAS_NO_REMOVE if not... maybe just #ifndef mos otherwise?

[mysterymath]

TODO(llvm-mos):

[mysterymath]

UINT32_C(1); then we probably shouldn't need the #if.

[kassane]

Missing #422 reference.