[libcxx] Port to NuttX(https://nuttx.apache.org/) RTOS

[xiaoxiang781216]

Summary

Since NuttX conform to POSIX standard, the code need to add is very simple

[xiaoxiang781216]

Updating D88718: [libcxx] Port to NuttX(https://nuttx.apache.org/) RTOS

[mclow.lists]

libcxx/include/__config

1127

How does __NuttX__ get defined?

libcxx/include/support/nuttx/xlocale.h

17

This change probably belongs in __config

24

Why all the #undefs?

[mclow.lists]

A general comment - is someone going to run a libc++ test bot for NuttX? Otherwise, how will we know when changes that we make to libc++ break NuttX support?

[ldionne]

Thanks for the contribution. It's nice to see a new platform that's as easy to support as this.

However, I'll echo Marshall's comment here. If we are to add support for a new platform, we need CI for it. Are you willing and able to provide that? We use BuildKite for CI and it's fairly simple to setup.

[xiaoxiang781216]

libcxx/include/__config

1127

It get defined in two ways:
1.Build toolchain target NuttX OS from here:

https://github.com/NuttX/buildroot
The result binary define __NuttX__ automatically just like how Linux toolchain define __linux__

2.Define NuttX from the board/toolchain specific Makefile, like this:

https://github.com/apache/incubator-nuttx/blob/master/boards/arm/imxrt/imxrt1050-evk/configs/libcxxtest/Make.defs#L77

libcxx/include/support/nuttx/xlocale.h

17

Yes, could be, but I want to minize the change as small as possible. But if you want, I will move the change to __config.

24

NuttX support a special target platform named sim which is basically a normal process running on Linux/macOS/Cygwin, but simulate all OS API inside it. Since it is built by the host toolchain, I have to undef these macros to avoid libcxx detect the wrong target. Here is more info about simulator:
https://cwiki.apache.org/confluence/display/NUTTX/NuttX+Simulation

[xiaoxiang781216]

In D88718#2308817, @mclow.lists wrote:

A general comment - is someone going to run a libc++ test bot for NuttX? Otherwise, how will we know when changes that we make to libc++ break NuttX support?

NuttX is RTOS, so the setup for both build and test is much hard than normal development environment(e.g. Linux, macOS or Windows):
1.We need prepare the cross build toolchain
2.We need build libcxx with NuttX OS together
3.We need run the test with the real hardware or simulator
It isn't suitable to incorporate this type of change into libcxx because it's too specific to NuttX environment. On the other hand, we plan to integrate libc++ test into NuttX daliy testing infrastructure, like what we have already done for Linux Test Project here:
https://github.com/apache/incubator-nuttx-apps/pull/410

[btashton]

(Also from the Apache NuttX team)
If what we set up on our end in CI is not sufficient enough, I would be willing to look at what needs to be done to provide that here via what you have in BuildKite. Supporting the simulator target probably would not be too difficult.

[ldionne]

In D88718#2355514, @btashton wrote:

(Also from the Apache NuttX team)
If what we set up on our end in CI is not sufficient enough, I would be willing to look at what needs to be done to provide that here via what you have in BuildKite. Supporting the simulator target probably would not be too difficult.

That would be great.

Otherwise, have you considered building with -DLIBCXX_ENABLE_LOCALIZATION=OFF? I added this "flavor" of libc++ specifically to cater to the needs of smaller OSes that don't provide localization support. The best case scenario would be if libc++ could work on your platform out-of-the-box without support for localization: that way, we wouldn't even have to add another configuration for libc++.

[xiaoxiang781216]

LIBCXX_ENABLE_LOCALIZATION is a great feature what we find it consume a large code size for small OS. Could you point me the change? I can't find LIBCXX_ENABLE_LOCALIZATION in libc++ 11.0.0 release.

[xiaoxiang781216]

@ldionne could you give more info about LIBCXX_ENABLE_LOCALIZATION?

[xiaoxiang781216]

Just find it here: https://reviews.llvm.org/D90072
I will change the porting to adapter the new flag, which is very important for the small embeded system.

[xiaoxiang781216]

Updating D88718: [libcxx] Port to NuttX(https://nuttx.apache.org/) RTOS

[xiaoxiang781216]

@ldionne and @mclow.lists, the update should address your comment except the test and local. both of them could be addressed in the new patch.

[xiaoxiang781216]

Updating D88718: [libcxx] Port to NuttX(https://nuttx.apache.org/) RTOS

[ldionne]

libcxx/include/__config

27

I'm not comfortable with undefining these macros here in libc++. Those are compiler-defined macros, and it's not libc++'s job to undefine them.

It seems to me that you either need a compiler target triple that understands NuttX, or to do whatever macro magic you want to do lower in the stack.

libcxx/include/__locale

25

Do you need this anymore? You shouldn't need it if you're using LIBCXX_ENABLE_LOCALIZATION=OFF.

[xiaoxiang781216]

libcxx/include/__config

27

Simulator is a special case here: It's a normal program run on Ubunutu or macOS and then should be compiled by host gcc toolchain, but all functions(POSIX, libc...) are provided by NuttX. If we don't undefine these macros, we have to modify every location where reference them. The later approach is very fragile and hard to maintain. Do you have other suggestion?

libcxx/include/__locale

25

Since stream and regex isn't supported when LIBCXX_ENABLE_LOCALIZATION=OFF, nuttx/xlocale.h is still needed to let the user turn on/off LIBCXX_ENABLE_LOCALIZATION as needed.

[xiaoxiang781216]

Updating D88718: [libcxx] Port to NuttX(https://nuttx.apache.org/) RTOS

[xiaoxiang781216]

@ldionne I move the toolchain macro undefinition to NuttX's Makefile, please review again.

[xiaoxiang781216]

@ldionne do you have time to review the update again?

[ldionne]

Do you have commit privilege? If so, please go ahead. Otherwise, please provide Author Name <email@domain> I should use when committing this for you.

libcxx/include/__config

27

Do you have other suggestion?

Yes, a compiler target triple that actually understands your platform.

[ldionne]

In D88718#2403748, @ldionne wrote:

Do you have commit privilege? If so, please go ahead. Otherwise, please provide Author Name <email@domain> I should use when committing this for you.

I have the memory of a goldfish. I asked you the same in D91074. I'll commit this for you, thanks!

[ldionne]

Just FYI, you also forgot to add support/nuttx/xlocale.h to libcxx/include/CMakeLists.txt, but I realized it when applying the patch locally and added it myself.

[xiaoxiang781216]

In D88718#2403771, @ldionne wrote:

Just FYI, you also forgot to add support/nuttx/xlocale.h to libcxx/include/CMakeLists.txt, but I realized it when applying the patch locally and added it myself.

Thanks for helping to add the new header file to CMakeLists.txt.

libcxx/include/__config

 #ifndef _LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER
 #pragma GCC system_header
 #endif
 
 #ifdef __cplusplus
 
 #ifdef __GNUC__
 #  define _GNUC_VER (__GNUC__ * 100 + __GNUC_MINOR__)
 // The _GNUC_VER_NEW macro better represents the new GCC versioning scheme
 // introduced in GCC 5.0.
 #  define _GNUC_VER_NEW (_GNUC_VER * 10 + __GNUC_PATCHLEVEL__)
 #else
 #  define _GNUC_VER 0
 #  define _GNUC_VER_NEW 0
 #endif
 
 #define _LIBCPP_VERSION 12000

 // Thread API
 #if !defined(_LIBCPP_HAS_NO_THREADS) && \
     !defined(_LIBCPP_HAS_THREAD_API_PTHREAD) && \
     !defined(_LIBCPP_HAS_THREAD_API_WIN32) && \
     !defined(_LIBCPP_HAS_THREAD_API_EXTERNAL)
 #  if defined(__FreeBSD__) || \
       defined(__wasi__) || \
       defined(__NetBSD__) || \
+      defined(__NuttX__) || \
       defined(__linux__) || \
       defined(__GNU__) || \
       defined(__APPLE__) || \
       defined(__CloudABI__) || \
       defined(__sun__) || \
       (defined(__MINGW32__) && __has_include(<pthread.h>))
 #    define _LIBCPP_HAS_THREAD_API_PTHREAD
 #  elif defined(__Fuchsia__)

libcxx/include/__locale

 #include <utility>
 #include <mutex>
 #include <cstdint>
 #include <cctype>
 #include <locale.h>
 #if defined(_LIBCPP_MSVCRT_LIKE)
 # include <cstring>
 # include <support/win32/locale_win32.h>
+#elif defined(__NuttX__)
+# include <support/nuttx/xlocale.h>
 #elif defined(_AIX)
 # include <support/ibm/xlocale.h>
 #elif defined(__ANDROID__)
 # include <support/android/locale_bionic.h>
 #elif defined(__sun__)
 # include <xlocale.h>
 # include <support/solaris/xlocale.h>
 #elif defined(_NEWLIB_VERSION)

libcxx/include/support/nuttx/xlocale.h

+// -*- C++ -*-
+//===-------------------- support/nuttx/xlocale.h -------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef _LIBCPP_SUPPORT_NUTTX_XLOCALE_H
+#define _LIBCPP_SUPPORT_NUTTX_XLOCALE_H
+
+#if defined(__NuttX__)
+#include <support/xlocale/__posix_l_fallback.h>
+#include <support/xlocale/__strtonum_fallback.h>
+
+#define _LIBCPP_PROVIDES_DEFAULT_RUNE_TABLE
+
+#undef __linux__
+#undef __unix__
+#undef __APPLE__
+#undef __GLIBC__
+#undef _NEWLIB_VERSION
+
+#endif // __NuttX__
+
+#endif

libcxx/src/include/config_elast.h

 #if defined(_LIBCPP_MSVCRT_LIKE)
 #include <stdlib.h>
 #else
 #include <errno.h>
 #endif
 
 #if defined(ELAST)
 #define _LIBCPP_ELAST ELAST
-#elif defined(_NEWLIB_VERSION)
+#elif defined(__NuttX__) || defined(_NEWLIB_VERSION)
 #define _LIBCPP_ELAST __ELASTERROR
 #elif defined(__Fuchsia__)
 // No _LIBCPP_ELAST needed on Fuchsia
 #elif defined(__wasi__)
 // No _LIBCPP_ELAST needed on WASI
 #elif defined(__linux__) || defined(_LIBCPP_HAS_MUSL_LIBC)
 #define _LIBCPP_ELAST 4095
 #elif defined(__APPLE__)

libcxx/src/locale.cpp

 #include "cstring"
 #if defined(_LIBCPP_MSVCRT)
 #define _CTYPE_DISABLE_MACROS
 #endif
 #include "cwctype"
 #include "__sso_allocator"
 #if defined(_LIBCPP_MSVCRT) || defined(__MINGW32__)
 #include "support/win32/locale_win32.h"
-#elif !defined(__BIONIC__)
+#elif !defined(__BIONIC__) && !defined(__NuttX__)
 #include <langinfo.h>
 #endif
 #include <stdlib.h>
 #include <stdio.h>
 #include "include/atomic_support.h"
 #include "__undef_macros"
 
 // On Linux, wint_t and wchar_t have different signed-ness, and this causes