[cfe-dev] [libc++] Porting libc++ to embedded targets/compilers

[David Chisnall via cfe-dev]

On 12 Sep 2017, at 22:41, Nagurne, James via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> Hello,
>  
> I am a developer in the compiler division (CodeGen) at Texas Instruments. Our compiler targets a variety of embedded targets from DSPs like the C6000 to microcontrollers like the C2000 and MSP430. All of our compilers use a common, modified EDG C++ front end accepting a majority of the C++14 standard in addition to many extensions allowed by both GCC and Clang, such as __has_feature.
>  
> We’re investigating using libc++ in addition to our home grown and augmented C (and C++ implementation-specific behavior) library to fill out our C++ support. Having worked on this for a week or so, I’ve cultivated a list of issues whose answers/solutions will help guide me in completing and trying to upstream some/all of this work.
>  
> - Atomic builtins (__sync functions) are assumed to exist, and other atomic issues
> Our first drop of C++14 will not have support for threads or atomics, since we’re still talking with other teams which support the low-level operations and APIs needed.
> The CMakelists.txt file checks for atomic support, warning “Host compiler must support std::atomic”. Is this a major problem that could stop us from being able to use libc++ immediately?
> For the __sync functions, we could define template functions to overload and perform the elemental operation without any guarantee of atomicity (I believe all uses are currently ‘int’ operations). Is this alright, assuming we will not be supporting multiple theads?

I believe that it’s a good idea to support std::atomic anyway for compatibility, but in a deployment environment where there will never be threads, an implementation of std::atomic can simply use non-atomic arithmetic (though if you need interrupt safety for the atomics then you might need a slightly more complex compare and exchange operation).
>  
> - Is there any documentation on what exceptions.cpp needs to be doing?
> From the looks of things, we need an implementation that defines everything in exception_fallback.ipp. If it’s as simple as that, great!

If you’re not throwing exceptions, exception_fallback should work for you.  For embedded targets, if you are throwing exceptions then you probably want the libcxxrt version (libcxxrt is a much smaller binary than libc++abi).
 
> - The proper way to handle ‘fallbacks’, which seem to exist in $LIBCXX_ROOT/include/support
> Our library doesn’t support the POSIX locales (e.g.: locale_t), nor does it support the ‘__<FPType>...’ predefined macros.
> I modeled the predefined macros after the limit_defs.h found in win32/ibm. I’m assuming that’s the correct process, but I just want to make sure.
> For locales, however, I couldn’t find a perfect analog, though the original fallback implementation in the git history came from Newlib, so I modeled after that header. It seems like the fallbacks completely negate the need for locale_t and _l variants of functions (and, thus, POSIX support), so that seemed like the right thing to do for our targets.

The C++11 locale support is designed to be a thin wrapper around POSIX2008 locales.  These are pretty heavy and likely not to be useful in an embedded target, where you’d only want to support the C locale (std::locale::classic).  In this case, all of these would be compiled away.  I don’t think we have such a fallback implementation, but a trivial one should be easy to write.

David