This is an archive of the discontinued LLVM Phabricator instance.

[N4917] Support C++23 freestanding for libcxx.
AbandonedPublic

Authored by Mordante on Dec 27 2022, 5:41 AM.

Details

Reviewers
trcrsired
philnik
Group Reviewers
Restricted Project
Summary

The C++23 [N4917] defines what freestanding headers need to provide. This allows clang to use with any target of freestanding C++ without providing a libc since implementing libc might be too hard. Plus we have a bootstrapping problem for libcs like mlibc which uses freestanding C++ to implement the libc.

The previous commit contains many patches, and it looks like the reviewers are unwilling to review them anymore.

Just start a new revision for freestanding.

Besides what the standard requires, we provide as many headers as possible for libcxx.

Freestanding will only provide headers, not any libs.

Diff Detail

Event Timeline

trcrsired created this revision.Dec 27 2022, 5:41 AM
trcrsired requested review of this revision.Dec 27 2022, 5:41 AM
trcrsired accepted this revision.
This revision is now accepted and ready to land.Dec 27 2022, 5:41 AM
philnik requested changes to this revision.Dec 27 2022, 5:57 AM
philnik added 1 blocking reviewer(s): Restricted Project.
philnik added a subscriber: philnik.

We are still not interested in implementing a libc. This configuration is also completely untested. A freestanding configuration also shouldn't override other settings. If someone wants a freestanding implementation but knows that wide characters are supported, one should be able to enable that part of the library. Any freestanding configuration consist only of library parts that are disabled. There is no reason to not require people to link against a library, so extern instantiations shouldn't be removed. All of these things were already mentioned in the other patch. Address the comments that you get. If you think there are good reasons not do do these things argue for your position or GTFO.

This revision now requires changes to proceed.Dec 27 2022, 5:57 AM
trcrsired added a comment.EditedDec 27 2022, 8:12 AM

We are still not interested in implementing a libc. This configuration is also completely untested. A freestanding configuration also shouldn't override other settings. If someone wants a freestanding implementation but knows that wide characters are supported, one should be able to enable that part of the library. Any freestanding configuration consist only of library parts that are disabled. There is no reason to not require people to link against a library, so extern instantiations shouldn't be removed. All of these things were already mentioned in the other patch. Address the comments that you get. If you think there are good reasons not do do these things argue for your position or GTFO.

i am not implementing a libc. i just define the little macros part what libc++ relies on (EOF for example) for freestanding. They are tiny. If users provide the libc headers, they will use the libc definitions. Headers like atomic in libc++ would rely on chrono. I define the time_t in ctime to trivialize the implementation and reduce the implementation burden.

extern instantiations for sort are disabled for the use cases like linux kernel driver. If someone wants to sort, it is not a good idea to link libc++.

The whole point is to allow a naive freestanding support without linkage.

I do not think I disabled features like wide characters.

Things like threading and filesystem, etc are not required by C++ standard to support them for freestanding. Like you said this is not for implementing a libc. If users need them, they just do not give -DLIBCXX_FREESTANDING=On to cmake and then use -ffreestanding provided by GCC/clang. That would force the library work in freestanding by relying a libc (exactly like what libstdc++ does). I think I do not disable threading for -ffreestanding under that setting.

atomic is a freestanding header, there is no point it would rely on an external threading library in freestanding since it violates C++ standard.

For exception handling, they are part of libc++abi and neither GCC libstdc++ correctly support exception handling in freestanding either. That is a defect of C++ standard since many targets do not have the ability for exception handling.

Whatever, your attitude has changed and that is a good start. I would follow everything you would like me to do to support this.

What C++ standard only requires those headers to be defined.

#  include <cstddef>
#  include <limits>
#  include <cfloat>
#  include <version>
#  include <cstdint>
#  include <cstdlib>
#  include <new>
#  include <typeinfo>
#  if __has_include(<source_location>)
#    include <source_location>
#  endif
#  include <exception>
#  include <initializer_list>
#  include <compare>
#  include <coroutine>
#  include <cstdarg>
#  include <concepts>
#  include <type_traits>
#  include <bit>
#  include <atomic>
#  include <utility>
#  include <tuple>
#  include <memory>
#  include <functional>
#  include <ratio>
#  include <iterator>
#  include <ranges>
#  include <typeinfo>

Features like algorithm are merely for extensions for be compatible with libstdc++ and trivialize the settings for users that would use certain features (like rely a string_view for their library for a certain API example). That are not meant to be 100% usable and that is not the point either. Users should not rely on those features too.

trcrsired updated this revision to Diff 490001.Jan 17 2023, 5:41 PM
trcrsired removed 1 blocking reviewer(s): Restricted Project.

Update libc++ for latest patch

Mordante commandeered this revision.Sep 4 2023, 10:29 AM
Mordante added a subscriber: Mordante.

This patch has been inactive for a long time. Since we want to clear our review queue before Phabricator becomes read-only closing this patch.

Mordante abandoned this revision.Sep 4 2023, 10:31 AM