Add FLAGS option for add_header_library, add_object_library,
add_entrypoint_object, and add_libc_unittest.
In general, a flag is a string provided for supported functions under the
multi-valued option `FLAGS`. It should be one of the following forms:
FLAG_NAME
FLAG_NAME__NO
FLAG_NAME__ONLY
A target will inherit all the flags of its upstream dependency.
When we create a target `TARGET_NAME` with a flag using (add_header_library,
add_object_library, ...), its behavior will depend on the flag form as follow:
- FLAG_NAME: The following 2 targets will be generated:
`TARGET_NAME` that has `FLAG_NAME` in its `FLAGS` property.
`TARGET_NAME.__NO_FLAG_NAME` that depends on `DEP.__NO_FLAG_NAME` if
`TARGET_NAME` depends on `DEP` and `DEP` has `FLAG_NAME` in its `FLAGS`
property.
- FLAG_NAME__ONLY: Only generate 1 target `TARGET_NAME` that has `FLAG_NAME`
in its `FLAGS` property.
- FLAG_NAME__NO: Only generate 1 target `TARGET_NAME.__NO_FLAG_NAME` that
depends on `DEP.__NO_FLAG_NAME` if `DEP` is in its DEPENDS list and `DEP`
has `FLAG_NAME` in its `FLAGS` property.
To show all the targets generated, pass SHOW_INTERMEDIATE_OBJECTS=ON to cmake.
To show all the targets' dependency and flags, pass
`SHOW_INTERMEDIATE_OBJECTS=DEPS` to cmake.
To completely disable a flag FLAG_NAME expansion, set the variable
`SKIP_FLAG_EXPANSION_FLAG_NAME=TRUE`.
Reviewed By: michaelrj, sivachandra
Differential Revision: https://reviews.llvm.org/D125174
Add LLVM_LIBC_CLANG_TIDY option and allow LLVM_LIBC_ENABLE_LINTING without full build.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D119180
CMAKE_CXX_STANDARD 14 is set in the llvm-project/llvm folder overriding all COMPILE_OPTIONS -std=c++17. We need to override the CXX_STANDARD property of the target in order to set the correct C++ standard flags.
Reviewed By: gchatelet
Differential Revision: https://reviews.llvm.org/D118871
The LLVM Libc project is no longer just a proposal and should have
a webpage tracking the status of the project. This changes
puts the pieces into the right place so that the webpage can be
created.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D117436
This is the original patch in my GNUInstallDirs series, now last to merge as the final piece!
It arose as a new draft of D28234. I initially did the unorthodox thing of pushing to that when I wasn't the original author, but since I ended up
- Using `GNUInstallDirs`, rather than mimicking it, as the original author was hesitant to do but others requested.
- Converting all the packages, not just LLVM, effecting many more projects than LLVM itself.
I figured it was time to make a new revision.
I have used this patch series (and many back-ports) as the basis of https://github.com/NixOS/nixpkgs/pull/111487 for my distro (NixOS), which was merged last spring (2021). It looked like people were generally on board in D28234, but I make note of this here in case extra motivation is useful.
---
As pointed out in the original issue, a central tension is that LLVM already has some partial support for these sorts of things. Variables like `COMPILER_RT_INSTALL_PATH` have already been dealt with. Variables like `LLVM_LIBDIR_SUFFIX` however, will require further work, so that we may use `CMAKE_INSTALL_LIBDIR`.
These remaining items will be addressed in further patches. What is here is now rote and so we should get it out of the way before dealing more intricately with the remainder.
Reviewed By: #libunwind, #libc, #libc_abi, compnerd
Differential Revision: https://reviews.llvm.org/D99484
This is the original patch in my GNUInstallDirs series, now last to merge as the final piece!
It arose as a new draft of D28234. I initially did the unorthodox thing of pushing to that when I wasn't the original author, but since I ended up
- Using `GNUInstallDirs`, rather than mimicking it, as the original author was hesitant to do but others requested.
- Converting all the packages, not just LLVM, effecting many more projects than LLVM itself.
I figured it was time to make a new revision.
I have used this patch series (and many back-ports) as the basis of https://github.com/NixOS/nixpkgs/pull/111487 for my distro (NixOS), which was merged last spring (2021). It looked like people were generally on board in D28234, but I make note of this here in case extra motivation is useful.
---
As pointed out in the original issue, a central tension is that LLVM already has some partial support for these sorts of things. Variables like `COMPILER_RT_INSTALL_PATH` have already been dealt with. Variables like `LLVM_LIBDIR_SUFFIX` however, will require further work, so that we may use `CMAKE_INSTALL_LIBDIR`.
These remaining items will be addressed in further patches. What is here is now rote and so we should get it out of the way before dealing more intricately with the remainder.
Reviewed By: #libunwind, #libc, #libc_abi, compnerd
Differential Revision: https://reviews.llvm.org/D99484
Generation of the .yaml has been removed to prevent lint from
running with every ninja invocation. The new .clang-tidy file is copied
to the libc build directory so that generated files also get checked.
Reviewed By: michaelrj
Differential Revision: https://reviews.llvm.org/D115405
This commit changes the clang-tidy rules for LLVM-libc to follow the new
format. The next commit applies these rules to the codebase.
The rules are as follows:
CamelCase for classes
lower_case for variables
lower_case for functions
UPPER_CASE for constexpr variables
There are also some exceptions, but the most important one is that any
function or variable that starts with an underscore is exempt from the
formatting.
Reviewed By: sivachandra, lntue
Differential Revision: https://reviews.llvm.org/D114301
Included more math functions to Windows's entrypoints
and made a cmake option (-DLLVM_LIBC_MPFR_INSTALL_PATH)
where the user can specify the install path where the MPFR
library was built so it can be linked. The try_compile was
moved to LLVMLibCCheckMPFR.cmake, so the variable that is
set after this process can retain its value in other files
of the same parent file. A direct reason for this is for
LIBC_TESTS_CAN_USE_MPFR to be true when the user specifies
MPFR's path and retain its value even after leaving the file.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D106894
This patch adds LLVM_LIBC_INCLUDE_SCUDO as a flag. When enabled it
should link in the standalone version of SCUDO as the allocator for LLVM
libc.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D106502
This matches the decision made in D99697.
It also shouldn't reintroduce the issue fixed in D99636.
The variable was originally introduced in
b22f448c21 but is not essential to that
change.
Once we finish adding `GnuInstallDirs` support in D100810 and D99484,
setting `CMAKE_INSTALL_LIBDIR` would also work to change the
installation directory (though for more than libc).
`GnuInstallDirs` support also brings up an issue which is avoided if
variables like `LIBC_INSTALL_PREFIX` don't exist. Because the
`GnuInstallDirs` variables can be absolute paths, it is a bit unclear
how the per-project prefixes would work: does the project-agnostic
role-specific variable (e.g. `CMAKE_INSTALL_LIBDIR`), or project-specfic
role-agnostic (e.g. `LIBC_INSTALL_PREFIX`) take priority? Each is more
specific than the other on one axis, but not the other.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D105740
Previously, we required entrypoints.txt for every target architecture
supported by a target OS. With this change, we allow architecture
independent config for a target OS. That is, if an architecture specific
entrypoints.txt is missing, then a generic entrypoints.txt for that
target OS will be used.
Reviewed By: caitlyncano
Differential Revision: https://reviews.llvm.org/D105147
This patch provides a way to specify the default target cpu optimizations to use when compiling llvm-libc.
This ensures we don't rely on current compiler's default and allows compiling and cross compiling for a particular target.
Differential Revision: https://reviews.llvm.org/D101991
Current implementation defines LIBC_TARGET_MACHINE with the use of CMAKE_SYSTEM_PROCESSOR.
Unfortunately CMAKE_SYSTEM_PROCESSOR is OS dependent and can produce different results.
An evidence of this is the various matchers used to detect whether the architecture is x86.
This patch normalizes LIBC_TARGET_MACHINE and renames it LIBC_TARGET_ARCHITECTURE.
I've added many architectures but we may want to limit ourselves to x86 and ARM.
Differential Revision: https://reviews.llvm.org/D101524
b22f448c21 added a rule to install libllvmlibc.a to
${LIBC_INSTALL_PREFIX}/${LIBC_INSTALL_LIBRARY_DIR}, which will be /lib
by default, which is disruptive to builds that stay within a user's
/home holder:
$ ninja install
...
-- Installing: /lib/libllvmlibc.a
CMake Error at projects/libc/lib/cmake_install.cmake:54 (file):
file INSTALL cannot copy file
"/home/nathan/cbl/github/tc-build/build/llvm/stage1/projects/libc/lib/libllvmlibc.a"
to "/lib/libllvmlibc.a": Permission denied.
Call Stack (most recent call first):
projects/libc/cmake_install.cmake:51 (include)
projects/cmake_install.cmake:47 (include)
cmake_install.cmake:76 (include)
...
Change LIBC_INSTALL_PREFIX's default value to ${CMAKE_INSTALL_PREFIX} so
that 'ninja install' does not attempt to install anything outside of the
user's requested installation location.
Differential Revision: https://reviews.llvm.org/D99636
Reviewed By: sivachandra
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
This option will build LLVM libc as a full libc by itself. In this mode,
it is not expected that it will be mixed with other libcs. The
non-full-build mode will be the default LLVM libc build mode. In a future
where LLVM libc is complete enough, the full libc build will be made the
default mode.
This is useful when cross-compiling libc to another target in which
case we first need to compile libc-hdrgen for host. We rely on the
existing LLVM CMake infrastructure for that.
Differential Revision: https://reviews.llvm.org/D95205
The function listings in api.td are removed. The same lists are now deduced using the information
in entrypoints.txt.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D89267
Summary:
To get the target order correct, the benchmarks directory has been moved
one level higher. Previously, it was living in the utils directory. The
utils directory is a collection of utils which are to be used by the
tests and implementations. However, benchmarks *use* the
implementations. So, moving it out of utils helps us setup proper
target level dependencies.
Reviewers: gchatelet
Differential Revision: https://reviews.llvm.org/D81910
Summary:
If a test depends on a skipped entrypoint, then the test is also
skipped. This setup will be useful as we gradually add support for
more operating systems and target architectures.
Reviewers: asteinhauser
Differential Revision: https://reviews.llvm.org/D81489
Summary: When building llvm-libc with linting enabled, clang-tidy would use the resource dir of the monorepo rather then the host compiler's resource dir. This presented issues when including headers from the host compiler e.g. for sanitizers. Therefore this patch explicitly tells clang-tidy to use the host compiler's resource dir.
Reviewers: sivachandra
Reviewed By: sivachandra
Subscribers: mgorny, tschuett, ecnelises, libc-commits
Tags: #libc-project
Differential Revision: https://reviews.llvm.org/D80265
Summary:
This patch implements running linting on llvm-libc using build rule targets.
1) adds a new target per entrypoint for linting with the naming convention `<qualified_target_name>.__lint__` e.g `libc.src.string.strlen.__lint__`.
2) makes the build target for each entrypoint depend on the linting targets so that they run along with compilation of each entrypoint.
3) adds a lint all target named `lint-libc`. `check-libc` now depends on this new target.
4) linting creates a lot of additional targets from clang and clang-tidy that need to be built so an opt out flag can be passed to cmake: `LLVM_LIBC_ENABLE_LINTING`.
Reviewers: sivachandra, abrachet
Reviewed By: sivachandra
Subscribers: abrachet, mgorny, tschuett, libc-commits
Tags: #libc-project
Differential Revision: https://reviews.llvm.org/D77861
Only targets setup by the special LLVM libc rules now have fully
qualified names. The naming style is similar to fully qualified names in
Python.
Reviewers: abrachet, PaulkaToast, phosek
Differential Revision: https://reviews.llvm.org/D77340
This adds a very simple loader. This will be extended to a full loader
in future patches. A utility rule to add unittests has been added to
serve us while we are building out the full loader.
Reviewers: abrachet, phosek
Differential Revision: https://reviews.llvm.org/D76412
Summary:
The patch is not ready yet and is here to discuss a few options:
- How do we customize the implementation? (i.e. how to define `kRepMovsBSize`),
- How do we specify custom compilation flags? (We'd need `-fno-builtin-memcpy` to be passed in),
- How do we build? We may want to test in debug but build the libc with `-march=native` for instance,
- Clang has a brand new builtin `__builtin_memcpy_inline` which makes the implementation easy and efficient, but:
- If we compile with `gcc` or `msvc` we can't use it, resorting on less efficient code generation,
- With gcc we can use `__builtin_memcpy` but then we'd need a postprocess step to check that the final assembly do not contain call to `memcpy` (unlikely but allowed),
- For msvc we'd need to resort on the compiler optimization passes.
Reviewers: sivachandra, abrachet
Subscribers: mgorny, MaskRay, tschuett, libc-commits, courbet
Tags: #libc-project
Differential Revision: https://reviews.llvm.org/D74397
Summary:
Added fuzzing test for strcpy and some documentation related to fuzzing.
This will be the first step in integrating this with oss-fuzz.
Reviewers: sivachandra, abrachet
Reviewed By: sivachandra, abrachet
Subscribers: gchatelet, abrachet, mgorny, MaskRay, tschuett, libc-commits
Tags: #libc-project
Differential Revision: https://reviews.llvm.org/D74091
Some of the existing utils in utils/UnitTest/Test.h have been moved to
this new library.
Reviewers: abrachet, gchatelet
Tags: #libc-project
Differential Revision: https://reviews.llvm.org/D73530
A toplevel target, `check-libc` has also been added.
Reviewers: abrachet, phosek
Tags: #libc-project
Differential Revision: https://reviews.llvm.org/D72177
Summary:
A set of of linux x86_64 internal syscall helpers have also been added.
This change does not try to be perfect with respect to OS and machine
abstractions. A TODO note has been added at places where such abstractions
would help and make the arrangement scalable and cleaner. Addressing the
TODOs and building such abstractions is not in the scope of this change.
It is hoped that follow up changes cleaning up the problem areas and
addressing the TODOs will better illustrate the need for the changes.
This change also does not try to imitate mmap and munmap implementations
of other libcs. The idea here is to put in the bare minimum required to
obtain a working mmap and munmap, and then add the rest of the
functionality on an as needed basis.
Reviewers: abrachet, phosek, stanshebs, theraven
Subscribers: mgorny, MaskRay, jfb, libc-commits
Tags: #libc-project
Differential Revision: https://reviews.llvm.org/D71634
Summary:
* The Python header generator has been removed.
* Docs giving a highlevel overview of the header gen scheme have been
added.
Reviewers: phosek, abrachet
Subscribers: mgorny, MaskRay, tschuett, libc-commits
Tags: #libc-project
Differential Revision: https://reviews.llvm.org/D70197
Summary:
This patch illustrates some of the features like modularity we want
in the new libc. Few other ideas like different kinds of testing, redirectors
etc are not yet present.
Reviewers: dlj, hfinkel, theraven, jfb, alexshap, jdoerfert
Subscribers: mgorny, dexonsmith, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67867
llvm-svn: 373764
Tue Ly