This fleshes out the <link.h> a little more, including the
`struct dl_phdr_info` type and declaring the dl_iterate_phdr
function. There is only a no-op implementation without tests, as
for the existing dlfcn functions.
Initial UEFI OS target support after the headers. This just defines
enough that stuff might try and compile. Test with:
```
$ cmake -S llvm -B build -G Ninja -DLLVM_RUNTIME_TARGETS=x86_64-unknown-uefi-llvm -DRUNTIMES_x86_64-unknown-uefi-llvm_LLVM_ENABLE_RUNTIMES=libc -DRUNTIMES_x86_64-unknown-uefi-llvm_LLVM_LIBC_FULL_BUILD=true -DCMAKE_C_COMPILER_WORKS=true -DCMAKE_CXX_COMPILER_WORKS=true -DLLVM_ENABLE_PROJECTS="clang;lld" -DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_LIBCXX=true -DLLVM_HOST_TRIPLE=aarch64-unknown-linux-gnu -DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-unknown-uefi-llvm -DCMAKE_INSTALL_LIBDIR=build/target/lib
$ ninja -C build
```
Move the hdrgen code under a subdirectory to treat it as a Python
module.
This mimics the structure used by llvm/utils/lit and
llvm/utils/mlgo-utils and simplifies integration of hdrgen to the build
system which rely on Python modules. In addition to that, it clarifies
which imports are coming from the hdrgen-specific helpers (e.g. "from
type import ..." becomes "from hdrgen.type import ...".
Leave the entrypoints (top-level main.py and yaml_to_classes.py) as-is:
they can keep being referred by the CMake build system w/o any changes.
This adds a feature to hdrgen to emit JSON summaries of header
files for build system integration. For now the summaries have
only the basic information about each header that is relevant for
build and testing purposes: the standards and includes lists.
Macros starting with alphabetic characters such as "LLVM" are in
the application name space and cannot be defined or used by a
conforming implementation's headers. This fixes the headers that
are entirely generated, and the __llvm-libc-common.h header to
use a conforming macro name for the header guard. That is, it
starts with "_LLVM_LIBC_" instead of "LLVM_LIBC_", as identifiers
starting with an underscore followed by a capital letter are in
the name space reserved for the implementation.
The remaining headers either will be fixed implicitly by removal
of their custom template files, or will need to be fixed by hand.
When the return type's rendering already doesn't end with an
identifier character, such as when it's `T *`, then idiomatic
syntax does not include a space before the `(` and arguments.
This allows a sort of "include" mechanism in the YAML files. A
file can have a "merge_yaml_files" list of paths (relative to the
containing file's location). These are YAML files in the same
syntax, except they cannot have their own "header" entry. Only
the lists (types, enums, macros, functions, objects) can appear.
The main YAML file is then processed just as if each of its lists
were the (sorted) union of each YAML file's corresponding list.
This will enable maintaining a single source of truth for each
function signature and other such details, where it is necessary
to generate the same declaration in more than one header.
This allows a YAML file to omit `template_header` and have no
`.h.def` file. A default template is generated based purely on
the information in the YAML file. This should handle most of the
cases. For now, it's exercised (aside from the hdrgen tests)
only for one of the simplest cases: <ctype.h>.
This includes making the parser notice the "standards" YAML field
at the top (header) level, not just in "functions" lists. The
standards listed for the header overall and for the individual
functions both feed into how a fully-generated header describes
itself in comments. To go with this, files using the default
generated template must stick to a new uniform set of spellings
for the "standards" lists. As more custom template files are
retired, the corresponding YAML files will need all their
standards lists normalized. For now, ctype.yaml is updated
with correct attribution for the POSIX `_l` extensions.
With this, the `types` list in YAML files should only be used to
list the types that a standard specifies should be in that header
per se. All the types referenced in function signatures will be
collected automatically.
This makes hdrgen emit `#include "..."` lines using the correct
relative path (number of `../` steps, if any) for the containing
header, and includes this in the sorted block of `#include` lines
also used for the macro headers.
A macro can specify macro_header instead of macro_value to
indicate that an llvm-libc-macros/ header file is supposed to
define this macro. This is used for dlfcn.h, which previously
bogusly redefined the RTLD_* macros to empty.
This avoids touching the output file when it hasn't changed. The
cmake build integration now uses this so that touching a .yaml or
.h.def file in ways that don't affect the generated header output
won't cause unnecessary recompilations.
This adds a new main command-line entry point for hdrgen, in the
new main.py. This new interface is used for generating a header.
The old ways of invoking yaml_to_classes.py for other purposes
are left there for now, but `--e` is renamed to `--entry-point`
for consistency with the new CLI.
The YAML schema is expanded with the `header_template` key where
the corresponding `.h.def` file's path is given relative to where
the YAML file is found. The build integration no longer gives
the `.h.def` path on the command line. Instead, the script now
emits a depfile that's used by the cmake rules to track that.
The output file is always explicit in the script command line
rather than sometimes being derived from a directory path.
The .yaml files should live next to the corresponding .h.def
files in libc/include/, rather than next to the implementation of
the tool in libc/utils/hdrgen/. As with the .h.def files, there
is no need for a yaml/ subdirectory under include/. This simpler
layout is more natural for maintenance and also simplifies build
integration outside the LLVM CMake build.
Two extra layers of subdirectory for a handful of single-symbol
Python source files did not improve anything, and it complicated
integration of the hdrgen Python outside the LLVM CMake build.
