In a recent PR (https://github.com/llvm/llvm-project/pull/174772), we
introduced GnuPropertySection using ElfW(Xword). Since we are currently
missing Elf32_Xword, this is failing on 32bit architectures.
This commit adds the missing Elf32_Xword type that should always hold
64bit even on 32bit architectures.
In order to add Control-flow Enforcement Technology (CET) Shadow Stack
(SHSTK) support, we need to parse the `PT_GNU_PROPERTY` program header
and the corresponding section to evaluate if the binary being started
was compiled with the necessary support.
PS: This is my first PR to llvm-libc, I might have made obvious styling
mistakes so I'd appreciate any feedback or suggestions to improve it.
I have a prototype branch using this change to enable SHSTK support:
https://github.com/jakos-sec/llvm-project/tree/add-shstk-support
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.
