[libcxx-dev] <atomic> for bare-metal development on ARM microcontrollers

Louis Dionne via libcxx-dev libcxx-dev at lists.llvm.org
Fri Jul 26 13:41:36 PDT 2019



> On Jul 26, 2019, at 16:26, JF Bastien <jfbastien at apple.com> wrote:
> 
> Hi Yves,
> 
>> On Jul 26, 2019, at 1:21 PM, Yves Delley <pu.y at delley.net <mailto: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.

Yup, let’s start by opening a Phabricator review and we’ll let you know what needs to satisfy our testing requirements!

Louis

> 
> 
>> 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 <https://github.com/burnpanck/docker-llvm-armeabi> once I have cleaned up the scripts a little. 
>> 
>> Yves
>> <0001-enable-atomic-header-on-thread-less-builds.patch><0001-explicitly-specify-location-of-libunwind-in-static-b.patch>
>> 
>> 
>> 
>>> On 3 Jul 2019, at 16:59, Louis Dionne <ldionne at apple.com <mailto:ldionne at apple.com>> wrote:
>>> 
>>> 
>>> 
>>> On Jul 3, 2019, at 10:06, Yves Delley <pu.y at delley.net <mailto:pu.y at delley.net>> wrote:
>>> 
>>>> 
>>>>> On 3 Jul 2019, at 15:49, Louis Dionne <ldionne at apple.com <mailto: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.
>>> 
>>> Louis
>>> 
>>>> 
>>>> Yves
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20190726/1eb530b5/attachment.html>


More information about the libcxx-dev mailing list