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

[Ben Craig via Phabricator via cfe-commits]

bcraig added a comment.

> Okay, so this is potentially ignorance on my part. I was under the impression that folks using freestanding mode did not want any library to be linked in. Are there freestanding libc implementations out there that the user would link in instead that we defer to (same as we defer hosted C standard library interfaces to the CRT)? Basically, do we need to do nothing in Clang to support N2524?

Well, people want all sorts of things :)

(Gross generalizations coming) The compiler writer view of freestanding that I've heard in the past is that the compiler writer views freestanding as the necessary parts of the library needed to support the language.  This is mostly accurate when describing freestanding prior to C++23 and C23.  Most of that is either header-only, in libc++abi, or in compiler-rt.  This makes testing the compiler a bit easier, as you don't need a full stdlib.  That's not a design goal of freestanding post C/C++23 though.  It's fine for Clang to provide half of a stdlib for internal testing or integration with other C libraries, so long as the final toolchain has everything.

One challenge for some customers will be that they like to build with `-nodefaultlibs`, but that's not a deal breaker here, it just means that they would need to manually put their C library on the link line.  Alternatively, they could start passing other linker flags, like `-nostartfiles` instead, but that will be use case dependent.  These kinds of hoops have historically been needed because a customer may use a "stock" ARM Clang, but not want to use the libc that came with that toolchain, so the big linker flags would come out to give the user control.

I don't think that Clang-the-compiler needs to do anything to support the new C/C++ freestanding features.  The main caveat being that you still need to be able to ensure the provided memcpy gets used instead of a codegenned (possibly vectorized) memcpy, but I think -ffreestanding already forces the compiler to generate calls and not use in-compiler codegen.

> FWIW, WG14 is having a second round of CD ballot comments. If you'd like, I'm happy to file a comment asking to remove strtok from the required set for freestanding conformance.

That would be much appreciated.  I can try to get my INCITS / ISO status squared away so that I can represent that issue at the appropriate meeting.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D144889/new/

https://reviews.llvm.org/D144889