aaron.ballman added a comment. In D144889#4157257 <https://reviews.llvm.org/D144889#4157257>, @jyknight wrote:
> In D144889#4156974 <https://reviews.llvm.org/D144889#4156974>, @rsmith wrote: > >> Likely because of GCC's perspective on this, the set of C headers provided >> by GCC, Clang, ICC, etc. has included the complete list of freestanding >> headers and more or less no others, with some libc implementations providing >> the full set and some providing just the non-freestanding ones. If we're >> moving away from that, we'll presumably need a new agreement between >> compiler folks and libc folks about which headers are provided by whom (and >> I expect it'll be "compilers provide what the C standard said before this >> change to freestanding and we pretend the change never happened"). > > Yeah...this seems like a pretty big divergence from the historical view > compilers have for "freestanding" mode, and I think the implementation should > be more along the lines of a "micro-libc", than something built into clang. > Especially considering the potential future additions e.g. `errno.h`. If we > look at this as a specification for what to provide in a "micro-libc", having > such global state is not a major issue, but if we look at this as a "compiler > builtin" sort of thing (ala traditional freestanding), then it's quite a > problem. On the one hand, I think many users will want a libc that targets their particular freestanding environment so that they get the best performance characteristics (and other considerations) for their target. This suggests the micro-libc approach. On the other hand, I think a not-insignificant number of users are interested in freestanding environments for one-off/fun/experimental projects where ease of access is more important than performance characteristics -- think: users who are playing around with an arduino, etc. This suggests a complete freestanding implementation may be preferable. It's somewhat hard to swallow to ask someone to go find a freestanding C library for a fun-time hardware project that might not have fantastic documentation just so the user can use `strlen` -- I suspect a nontrivial number of those folks are going to write their own `strlen` function and be done with it rather than try to solve C and C++'s terrible lack of package management. But it's also an awful lot of effort to write a custom implementation of `strtok` on the off chance a fun-time hardware project might want to use it. tl;dr: I don't know there's a clear "winner" approach, but I want to make sure we keep in mind the user experience for the full breadth of users we support. > So, I think the correct solution here is to just document what parts of a > C2x-conforming "freestanding" Clang provides itself, and what remains for an > external "mini-libc" implementation to provide. I think that makes sense. From what I'm reading, it sounds like that documentation is effectively pointing out that `-ffreestanding` mode in Clang will provide headers containing type definitions and macros for target-specific information that only the compiler knows about, expects the user to provide an implementation of `memcpy`, `memmove`, and `memset` (others?), but otherwise leaves all freestanding C standard library functions up to a user-provided library. Is that about what we'd want to document or do you expect more? (I can try to put together some docs we can iterate on.) > It probably makes sense for one such external implementation to be provided > by llvm-libc in the future -- I suspect it should have a separate > "freestanding" target mode, which would omit all the runtime features like > memory allocation and threads, and provide just the pure library > functionality. But I'd also expect such an llvm-libc freestanding mode would > also provide a lot more functionality than just the minimum requirements -- > there's a whole lot more "pure library" functions in C than just the ones > required in the new "freestanding" standard. +1 Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D144889/new/ https://reviews.llvm.org/D144889 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
