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

[Nagurne, James via cfe-dev]

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?

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

- The CMake system seems to assume a Clang/GCC-like or a Microsoft command line.
For example, there are assumptions made about what options exist and look like. A solid example is the pre-inclusion option, which is '-include' for Clang/GCC and '/FI' for Microsoft. Our compiler expects the option to be '--preinclude'.

There are two solutions I've discussed internally that I'd like some input on:
The first is creating a wrapper script that will make our compiler act like GCC/Clang by translating options to what our compiler expects. This is not work that can be upstreamed, and would be more difficult for us to maintain in case of changes to libc++ since we'll have to update our scripts whenever a new option is assumed by cmake. However, this avoids potentially bloating the CMake files with yet another compiler option set.

The second is to provide new attributes in the CMakelists.txt file that we can leverage to tell the build system what the option looks like. For example, for the '-include' and '/FI' switch, I could add LIBCXX_PREINCLUDE_OPTION, which defaults to either -include or /FI depending on COMPILER_ID. This makes things easier on our end, but will add extra work in CMakeLists.txt for each new option added to libc++ from here on out.

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

Fun fact: include/utility uses __CHAR_BIT__ but doesn't include limits as far as I could see. Before I added __CHAR_BIT__ to our compiler, we were expanding the size_t parameter in __murmur2_or_cityhash to 0. Does Microsoft/IBM, who also define __CHAR_BIT__ in an include/support header, have this happen?

- The implementation of std::random_device does not support utilizing a random number engine in the absence of implementation-specific non-deterministic RNGs
Two third-party library solutions, arc4 and Sodium, and two /platform-specific solutions, Unix-like /dev/random and Microsoft srand_s are supported.
Could a fallback macro be used to implement random_device via another engine found in the random header? I think std::mt19937 is the simplest random engine that supports the full range of values of unsigned int.

If you'd like, I can split these questions out into separate threads so we can get into things in more detail.
We appreciate any opinions or comments on this project outside of the questions posed here, as well. I'm pretty new to not only the libc++ source, but also to llvm, clang, and even cmake. I'm slowly learning my way around, but I don't purport to be fluent quite yet!

Thanks for your time,
J.B. Nagurne
Code Generation
Texas Instruments
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170912/69d03d72/attachment.html>