Initial support for building libcxx/libcxxabi on MOS. #310
Conversation
|
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 |
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...
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.
Probably. I meant "building libcxx/libcxxabi" in a very literal sense. |
| { | ||
| _LIBCPP_HIDE_FROM_ABI _LIBCPP_DISABLE_UBSAN_UNSIGNED_INTEGER_CHECK | ||
| _Size operator()(const void* __key, _Size __len) const { | ||
| // TODO: This is a stub implementation. Implement something better. |
There was a problem hiding this comment.
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.
|
|
||
| using ::fopen _LIBCPP_USING_IF_EXISTS; | ||
| using ::freopen _LIBCPP_USING_IF_EXISTS; | ||
| #ifndef _LIBCPP_HAS_NO_REMOVE |
There was a problem hiding this comment.
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?
| // | ||
| //===----------------------------------------------------------------------===// | ||
|
|
||
| // FIXME: This file does not compile correctly under LLVM-MOS. |
| using _Uint_type = uint32_t; | ||
|
|
||
| #if defined(__mos__) | ||
| static constexpr uint32_t _Exponent_mask = (1ul << _Exponent_bits) - 1; |
There was a problem hiding this comment.
UINT32_C(1); then we probably shouldn't need the #if.
2550bb7 to
7468b89
Compare
|
Missing #422 reference. |
Starting point for #198 ; part of #233 ; probably resolves llvm-mos/llvm-mos-sdk#52 though may need more adaptation work with time.
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.ccseems to work (albeit withheap_limitetc. needing to be replaced by__heap_limitetc. - 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.