[PATCH] D144889: [C2x] Support <string.h> in freestanding

Tue Feb 28 08:02:24 PST 2023

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