Bringup on a New OS or Architecture¶
If you are contributing a port for an operating system or architecture which is not covered by existing CI builders, you will also have to present a plan for testing and contribute a CI builder. See this guide for information on how to add new builders to the LLVM buildbot. You will either have to extend the existing Linux script and/or Windows script or add a new script for your operating system.
If you are starting to bring up LLVM’s libc on a new operating system, the first
step is to add a directory for that OS in the
libc/config directory. Both
the two operating systems on which LLVM’s libc is being actively developed,
have their own config directory.
Windows development is not as active as the development on Linux. There is a Darwin config also which is in a similar state as Windows.
LLVM’s libc is being brought up on the Fuchsia operating system also. However, there is no config directory for Fuchsia as the bring up is being done in the Fuchsia source tree.
If the Fullbuild Mode is to be supported on the new operating system,
then a file named
api.td should be added in its config directory. It is
written in the
LLVM tablegen language.
It lists all the relevant macros and type definitions we want in the
public libc header files. See the existing Linux
file as an example to prepare the
api.td file for the new operating system.
In future, LLVM tablegen will be replaced with a different DSL to list config information.
There are parts of the libc which are implemented differently for different
architectures. The simplest example of this is the
syscall function and
its internal implementation - its Linux implementation differs for different
architectures. Since a large part of the libc makes use of syscalls (or an
equivalent on non-Linux like platforms), it might be simpler and convenient to
bring up the libc for one architecture at a time. In such cases, wherein the
support surface of LLVM’s libc differs for each target architecture, one will
have to add a subdirectory (within the config directory os the operating
system) for each target architecture, and list the relevant config information
separately in those subdirectories. For example, for Linux, the x86_64 and
aarch64 configs are in separate directories, named
The libc CMake machinery looks for subdirectories named after the target
One of the important pieces of config information is listed in a file named
entrypoints.txt. This file lists the targets for the entrypoints (see
Entrypoints in LLVM libc) you want to include in the static archive of the libc (for
the Overlay Mode and/or the Fullbuild Mode.) If you are doing an
architecture specific bring up, then an
entrypoints.txt file should be
created in the architecture subdirectory for each architecture. Else, having a
entrypoints.txt in the operating system directory is sufficient.
A typical bring up procedure will normally bring up a small group of entrypoints
at a time. The usual practice is to progressively add the targets for those
entrypoints to the
entrypoints.txt file as they are being brought up. The
same is the case if one is implementing a new entrypoint - the target for the
new entrypoint should be added to the relevant
entrypoints.txt file. If
the implementation of the new entrypoint supports multiple operating systems and
target architectures, then multiple
entrypoints.txt files will have to be
Another important piece of config information is listed in a file named
headers.txt. It lists the targets for the set of public headers that are
provided by the libc. This is relevant only if the libc is to be used in the
Fullbuild Mode on the target operating system and architecture. As with
entrypoints.txt file, one
headers.txt file should be listed for
each individual target architecture if you are doing an architecture specific
bring up. The Linux config has
headers.txt file listed separately for the
config and the