[libcxx-dev] <atomic> for bare-metal development on ARM microcontrollers
JF Bastien via libcxx-dev
libcxx-dev at lists.llvm.org
Fri Jul 26 13:26:03 PDT 2019
> On Jul 26, 2019, at 1:21 PM, Yves Delley <pu.y at delley.net> wrote:
> Hi all,
> I managed to compile a static build of libc++ bleeding edge (just before the forking of the release branch) for armv7em baremetal supporting `<atomic>`, with a few minimal changes. I know, the timing with respect to the release of 9.0.0 is terrible. Nonetheless, the corresponding patch is attached to this eMail. It consists essentially of three changes:
> 1. Do not blindly refuse <atomic> when _LIBCPP_HAS_NO_THREADS is defined. I removed corresponding `#error` at the top of `<atomic>`. Furthermore, I changed the logic in `<__config>` where _LIBCPP_HAS_NO_ATOMIC_HEADER is determined to ignore _LIBCPP_HAS_NO_THREADS.
> 2. In `<__config>`, define _LIBCPP_ATOMIC_ONLY_USE_BUILTINS when _LIBCPP_HAS_NO_THREADS is defined (instead of just when _LIBCPP_FREESTANDING is defined), since there is no other way to implement <atomic> without thread support. Arguably, when building without thread support, one is effectively doing a freestanding compilation, so one could require the user to supply “-ffreestanding”. However, it seems that this is not usually done on the systems I work with. Furthermore, it is conceivable that one wants to build libc++ for a hosted platform that does not supports threads but still would want to have support for atomics.
> 3. In `memory.cpp`, change `#ifdef _LIBCPP_HAS_NO_ATOMIC_HEADER` to `#ifdef _LIBCPP_HAS_NO_THREADS`. Since this ifdef protects against the use of threading primitives, the latter seems more correct, while the former leads to compilation errors with the new logic for _LIBCPP_HAS_NO_ATOMIC_HEADER. It seems to indicate that the implementation of `<memory>` uses threading primitives instead of atomics. Therefore, in standalone builds, where concurrency comes in the form of interrupts rather than threads, one has to be careful with the use of `<memory>`. If at some point libc++ on baremetal becomes officially supported, that issue should probably be documented somewhere.
> I would like to contribute this patch, is this mailing list a good place to initiate the process.
The best place to contribute a patch is Phabricator, as detailed here: https://llvm.org/docs/Contributing.html <https://llvm.org/docs/Contributing.html>
> Of course, so far my patch fails to provide tests for the issue, which I’m not sure how to proceed with. I have never run any of the LLVM tests myself, as this seems to be extra challenging for cross-builds for baremetal.
I’ll let the libc++ maintainers chime in on that part.
> In order to build a static library of libc++abi including libunwind, I had to work around a separate issue in libc++abi for out-of-tree builds. The problem is that the final merge step for libc++abi expects to find the location of the libunwind archive from the CMake target, which only exists for in-tree builds. To me, that seems like a bug in the CMake scripts for libc++abi - I would assume that the intention is to support static builds for out-of-tree builds. Note that in-tree builds didn’t work for me because the configure step chokes on the baremetal compiler as the “host compiler" to build LLVM - ironically, because it determines that the “host compiler” doesn’t support atomics. I worked around that by introducing another CMake variable that let’s me specify the location of libunwind explicitly. Those changes are also in the attachment as a separate patch. However, I’m not sure that my work around is really an acceptable solution to the issue. Consider this just an attempt at a bug-report. I will share the details of my CMake configuration at https://github.com/burnpanck/docker-llvm-armeabi once I have cleaned up the scripts a little.
>> On 3 Jul 2019, at 16:59, Louis Dionne <ldionne at apple.com> wrote:
>> On Jul 3, 2019, at 10:06, Yves Delley <pu.y at delley.net> wrote:
>>>> On 3 Jul 2019, at 15:49, Louis Dionne <ldionne at apple.com> wrote:
>>>> […] Yves, would you be willing to check it out and report on whether it works? We may be able to get a simple patch in.
>>> I have an important project to wrap up until mid next week, I won’t have time before that. Afterwards, I’ll definitely give it a try. I should be able to report until the end of the coming week, if that’s ok.
>> Absolutely. It’s not like you owe us anything :). Looking forward to your report.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the libcxx-dev