<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jul 26, 2019, at 16:26, JF Bastien <<a href="mailto:jfbastien@apple.com" class="">jfbastien@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Yves,<br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Jul 26, 2019, at 1:21 PM, Yves Delley <<a href="mailto:pu.y@delley.net" class="">pu.y@delley.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi all,<br class=""><br class="">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:<br class=""> 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.<br class=""> 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.<br class=""> 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.<br class=""><br class="">I would like to contribute this patch, is this mailing list a good place to initiate the process.</div></div></blockquote><div class=""><br class=""></div><div class="">The best place to contribute a patch is Phabricator, as detailed here: <a href="https://llvm.org/docs/Contributing.html" class="">https://llvm.org/docs/Contributing.html</a></div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="">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.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">I’ll let the libc++ maintainers chime in on that part.</div></div></div></div></blockquote><div><br class=""></div><div>Yup, let’s start by opening a Phabricator review and we’ll let you know what needs to satisfy our testing requirements!</div><div><br class=""></div><div>Louis</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="">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 <a href="https://github.com/burnpanck/docker-llvm-armeabi" class="">https://github.com/burnpanck/docker-llvm-armeabi</a> once I have cleaned up the scripts a little. <br class=""><br class="">Yves<br class=""><span id="cid:953C4213-7CE5-4B31-82BC-1697A736CA06@apple.com" class=""><0001-enable-atomic-header-on-thread-less-builds.patch></span><span id="cid:0BCF8643-C611-48B3-A5AA-B9AAAD893E7B@apple.com" class=""><0001-explicitly-specify-location-of-libunwind-in-static-b.patch></span><br class=""><br class=""><br class=""><br class=""><blockquote type="cite" class="">On 3 Jul 2019, at 16:59, Louis Dionne <<a href="mailto:ldionne@apple.com" class="">ldionne@apple.com</a>> wrote:<br class=""><br class=""><br class=""><br class="">On Jul 3, 2019, at 10:06, Yves Delley <<a href="mailto:pu.y@delley.net" class="">pu.y@delley.net</a>> wrote:<br class=""><br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class="">On 3 Jul 2019, at 15:49, Louis Dionne <<a href="mailto:ldionne@apple.com" class="">ldionne@apple.com</a>> wrote:<br class=""><br class="">[…] 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.<br class=""></blockquote><br class="">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.<br class=""></blockquote><br class="">Absolutely. It’s not like you owe us anything :). Looking forward to your report.<br class=""><br class="">Louis<br class=""><br class=""><blockquote type="cite" class=""><br class="">Yves<br class=""></blockquote></blockquote><br class=""></div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></body></html>