Sync-up 10-1-2024 #2
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Introduced a configuration file which enables several optimisation flags. Change-Id: Idf6334f828177e7facfb12bbbb6a0159a877ee31
Applying the 0002-libc-tests-with-picolibc-disable-large-tests.patch llvm-project patch failed because of llvm-project commit 3497500946c9b6a1b2e1452312a24c41ee412b34: "[libc++] Clean up and update deployment target features (#96312)" This patch should make the application succeed again.
I've renamed it so it doesn't have NEWLIB in the name: now it's just
called `LLVM_TOOLCHAIN_LIBRARY_OVERLAY_INSTALL`. You configure it to
make an overlay package of newlib in particular by also defining
`LLVM_TOOLCHAIN_C_LIBRARY=newlib` (which you already had to do anyway,
even with the previous option name).
The old option name is no longer a cmake cache entry, but it is
detected on the command line, and used to set the default for the new
option. So existing cmake command lines should still work.
I've also removed some of the literal uses of the string 'newlib' in
code conditionalised by the option. Now those strings are obtained by
expanding `${LLVM_TOOLCHAIN_C_LIBRARY}`. So when we add another libc
type in the next commit, they should automatically adapt.
This is extremely new and barely tested: I've compiled and run a hello-world program, and that is literally all. But that's a start – if you can do that, you can also investigate what else does and doesn't compile or run successfully. So this is enough to allow users to experiment. As documented in the new `docs/llvmlibc.md`, this currently builds C libraries only (not C++), for AArch32 only. I don't know how much effort it will take to fix each of those: I only know that in each case _at least one_ cause of build failure exists, but I don't know how many more are hiding behind that one. You can use the new `-DLLVM_TOOLCHAIN_C_LIBRARY` with or without the option to build an overlay package. If you have both a newlib and an llvm-libc overlay package, then it should be possible to install both alongside each other on top of the same main toolchain. Unlike picolibc and newlib, llvm-libc doesn't come with a crt0.o startup file. Compiled for bare metal (as we're doing here), it also leaves some support functions undefined (e.g. for writing to stdout or stderr), expecting the user to provide them. So I've also added a small source directory containing the missing pieces. That builds two additional libraries, -lcrt0 and -lsemihost. At present, I haven't set up a llvm-libc specific ld script, and there's no code in my new crt0 that copies RW data out of ROM (as there is in picolibc). The only definition required by the crt0 is `__stack`, which you can define via an ld script of your own if you want, or directly on the ld.lld command ilne if you prefer.
This copies `libc/LICENSE.TXT` from the llvm-project repository into the `third-party-licenses` directory, renamed to `LIBC-LICENSE.TXT` so you can tell it apart from all the other subdirectory licenses. (We were already doing similar renames for libcxx, libunwind, etc.) When you build the toolchain in llvm-libc-only mode, that file shows up along with all the others at the top level of `third-party-licenses`. If you build an overlay package, it ends up in the `third-party-licenses/llvmlibc` subdirectory.
…s long one (#457) Co-authored-by: Vrukesh V Panse <[email protected]>
The motivation for this change is that users may wish to disable LTO when using the the Omax.cfg file. Removing the LTO flags to a seperate file allows the user to enable LTO related flags seperately. Change-Id: Id9ed8d8051f7ca4611b640f838715f658790d9cf
#458) Co-authored-by: Vrukesh V Panse <[email protected]>
* Update pre-requisite for executing on Windows 10 and Windows 11 * Update pre-requisite for executing on Windows --------- Co-authored-by: Vrukesh V Panse <[email protected]>
* Do not default to linking crt0 when using crt0-semihosting This commit adds the -nostartfiles option to tests using semihosting. This is in response to a recent change in clang which modified the driver to include crt0.o in the link: llvm/llvm-project#101258 While the change to clang removes the need to include the crt0 library directly, the tests using semihosting need to link against a different crt0 library. Therefore the new default behavior needs to be suppressed in these cases, which can be done by adding the -nostartfiles option. * Also remove -lcrt0 from make.bat
Updating the README.md file to detail usage of Omax.cfg and OmaxLTO.cfg.
I made two mistakes in this function: it used size_t without including any header file that defines it, and it was indecisive about whether its argument was called `code` or `status`. But both mistakes only affected the AArch64 branch of the #ifdef, which we weren't using yet, so they didn't cause a compile failure.
We couldn't previously build AArch64 llvmlibc, because the build failed due to lack of setjmp/longjmp. But now llvmlibc does have those functions for AArch64, so we can make building AArch64 library variants unconditional again, not dependent on which libc you want. The other missing thing for AArch64 is a configuration file in libc/config/baremetal (it only has configurations for two architectures, and AArch64 isn't one of them). I think the easiest approach is to reuse the AArch32 configuration, so that we build the same set of library functions into all our bare-metal libraries, 32- or 64-bit.
llvmlibc used to use a 32-bit time_t unconditionally on AArch32, commented as being for compatibility with glibc. But now it has an option to choose 64-bit instead, if you don't need to conform to glibc's ABI. A bare-metal libc indeed has no need to worry about glibc's time_t ABI (even for so long as it _stays_ 32-bit, which is probably not much longer). So it makes sense for us to use 64-bit time_t from the start, by setting the new config option.
llvmlibc's own test suite is written in C++, just like the library itself. But unlike the library, the test suite also depends on having a C++ library available: it uses iostreams, fstreams, vectors and so on. So until it's possible to build libc++ on top of a bare-metal version of llvmlibc, I can't see how we'd be able to run the tests.
…--defsym for library selection (#463) * Document the behaviour difference between LLD and GNU LD while using --defsym for library selection * Addressing the comments. 1. Add backquotes 2. Add the reference to https://github.com/picolibc/picolibc/blob/main/doc/printf.md 3. rephrase some words. * Addressing the suggestions about wording/formatting.
Commit hash e434fa1f41a83a888d6498922ab7f140011933d1 was the last one working. Set it as the default revision while recent breakages are not fixed.
A header comment in CMakeLists.txt suggests a sequence of commands for manually checking out the source repos and applying the patches. But it doesn't work, because it includes the command git -C repos/llvm-project am -k ../../patches/llvm-project/*.patch which, under POSIX shell semantics, is handled by first trying to expand the wildcard, then running the git command, which will change directory into `repos/llvm-project` because of the `-C` option. But the command only works if the wildcard is expanded _after_ changing directory, because the `../..` on the front of the pathname is intended to get back out of `repos/llvm-project`. To fix this, I've replaced the relative paths with `$PWD`, which will be expanded before git changes directory, so the pathnames will refer to the root of this repo. (I wondered if the command would have worked as written on Windows, where wildcards are expanded by the application and not the shell. But it doesn't look like it: on Windows, `git am` doesn't seem to expand wildcards at all. So it would be much more painful to rewrite this command sequence in a Windows-compatible way, and in this commit I haven't tried.)
In the `Building` section of building-from-source.md, twice we are trying to
apply a patch with the following command:
git -C repos/<repo> am -k "$PWD"/../patches/<repo>/*.patch
This command is executed from the root of the repo. The original thought
for this must have been that because of the `-C`, our path at time of
execution is `repos/<repo>`, and thus we need to move a level up from our
current directory. However `$PWD` will be replaced by the shell before the
command is executed. So we need to remove the spurious `../`.
This adds the folowing library variants with support for the PACBTI-M architecture extension: * armv8.1m.main_soft_nofp_nomve_pacret_bti[_exn_rtti] * armv8.1m.main_hard_fp_nomve_pacret_bti[_exn_rtti] * armv8.1m.main_hard_fpdp_nomve_pacret_bti[_exn_rtti] * armv8.1m.main_hard_nofp_mve_pacret_bti[_exn_rtti] Unfortunately, qemu currently doesn't provide support for PACBTI-M, which means these variants can't be fully tested at runtime level. Since the PACBTI-M instructions are NOP-copatible, we can use an arvm8.1m.main CPU as a workaround to ensure that the library code still works correctly regardless of branch protection.
* Added commands to set CC and CXX variables for current execution environment for example build commands list --------- Co-authored-by: Timur <[email protected]> Co-authored-by: timur.khasanshin <[email protected]>
This adds the `fenv` and `math_errhandling` tests to the set of disabled tests for the PACBTI-M library variants, introduced by #467. These tests were already disabled for the previously existing variants, due to a known issue in compiler-rt where the floating point exceptions are not set correctly for computations on types implemented in software.
One of our xfailed tests has been fixed, and the patch adding the xfail comment was causing a conflict.
Now that the limits.h issue [^1] has been resolved in picolibc upstream [^2], we can go back to its latest HEAD. [^1]: Commit hash cdc4fc3 [^2]: picolibc/picolibc#810
The instruction set (ARM/Thumb) is included in the triple, but doesn't matter for library selection because the ISA can be switched on any function call. This adds match blocks to multilib.yaml to treat thumb triples as if they were arm triples for library selection. This will also be needed for AArch32 v8-A and v8-R, but we don't have any libraries for them yet.
This is a GCC name for v7-A with the virtualisation extension, so for library selection we can treat it the same as v7-A.
This patch failed to apply for me in a manual `git am`, because the upstream addition of `ADDITIONAL_COMPILE_FLAGS` was just close enough to our change to confuse git. Regenerated that hunk. Now it still makes the same change, just without complaining.
The only differece between v7-M and v7E-M is the DSP extension, which is not useful for the C/C++ libraries, so we can simplify things by just having v7-M builds. This fills in a gap of (v7-M, fpv4-sp-d16, hard-float), which we did not previously have a valid library for.
This will prevent C++ links from breaking when llvm/llvm-project#101259 lands, as that removes -lc++abi and -lunwind from the linker command-line.
This patch fixes a few issues in the AArch64 nofp variants:
- AArch64 nofp variants without exceptions and RTTI must have higher
priority
The presence of `-fno-exceptions` and `-fno-rtti` in the driver
invocation causes matching with two variants: the one with
RTTI/Exceptions and the one without.
In the multilib system, the last match is the one that wins, therefore
in the JSON file we must list the variant without RTTI/Exceptions
*after* the one with.
- Enable exceptions and RTTI in the build of aarch64 nofp variants
supposed to have them
#599) Update the patch file with upstream changes of test_demangle.pass.cpp
This patch fixes the multilib flags required to select the AArch64 soft nofp variants. The `+nofp` and `+nosimd` arch extensions are specified in the `-march` or `-mcpu` command line options. Before this patch, the multilib flags specified this part as `-march=armv8-a+nofp+nosimd`, however this does not work for any architecture greater than v8, including point releases, nor does it for any `-mcpu` value whose underlying architecture is greater than v8. In the former case because any point release would lead to a regular expression mismatch; and in the latter, `-mcpu` option processing introduces extra architecture extensions in the string. Hence the correct way is to match agains `-march=armvX+nofp` and `-march=armvX+nosimd`. These two multilib flags are inserted by our implementation of `multilib.yaml` when `+nofp` and `+nosimd` are present anywhere in the `-march=` or `-mcpu=` values, respectively.
This patch was merged in upstream picolibc: picolibc/picolibc#895
32bitmicro
pushed a commit
that referenced
this pull request
Dec 18, 2024
This patch is a combined cherry-pick of three LLVM trunk commits: 7ddc32052546abd41656d2e670f3902b1bf805a7 5afbed1968588fe443a8a55053c2f1eaa321d28e 2cbe5a33a5fda257747d75863bd9ccb8920b9249 The first one implements support in llvm-objcopy for writing output in the S-record hex format. The other two are tiny fixes for build failures introduced by the first patch. These patches were committed on LLVM trunk by the following authors: 7ddc32052546abd (the main patch): quic-areg <[email protected]> 5afbed1968588fe (build fix #1): Jon Roelofs <[email protected]> 2cbe5a33a5fda25 (build fix #2): Maksim Panchenko <[email protected]>
This adds a patch file that reverts the order of libraries added on the command line to previously working one to avoid error about duplicate __aeabi_mem* symbols. This patch will be removed, once we implement a proper permanent solution in llvm-project.
Pull request #109628 automatically turned on frame pointers for leaf functions in Clang when frame pointers are enabled. This triggered a latent bug in picolibc for armv4t and armv5te, which consequentially broke our tests for them. There is currently a pull request that fixes this bug (picolibc/picolibc#897), but we don't have to wait for this to merge to reinstate the tests, because we recently changed the behaviour of Clang to by default omit frame pointers altogether (llvm/llvm-project#117140), and that is how picolibc is built now. In general the advice is that you shouldn't build AArch32 targets with frame pointers enabled for various reasons.
We've decided to have just two variants here: one with and one without RTTI and exceptions. We will not have variants across the strict aligment dimension. And since a strictly aligned variant is more compatible than one that's not, this change is made.
The tests check if the same variant is chosen with or without `-mno-unaligned-access`. For AArch64 A-profile big endian we provide only strictly aligned libraries.
This patch adds AArch32 base variants with `-mno-unaligned-access`. Base variants are the set of libraries that provide the most compatible functionality. As a consequence, they are built with strict alignment in order to work nicely with client code that is compiled with or without strict alignment.
This patch extends OmaxLTO with extra flags
Newlib overlay package has calls to init and fini. When building newlib, referencing of _init and _fini has been suppressed by undefining the corresponding macro HAVE_INIT_FINI and relys on the more modern .init_array and .fini_array. But the name of this macro in newlib has changed from HAVE_INIT_FINI to _HAVE_INIT_FINI, so undefine this macro in the cmake file..
This patch gives execution permissions to this Python script and fixes one wrong variable name. Since this script is used as an executable in our lit tests, it ought to have execution rights.
The lit tests under test/multilib must have a newline at the end of the file so that FileCheck checks with "-EMPTY" work correctly.
…630) Each library variant build consists of three subprojects, which require sequential configuring and building. While the build steps can be parallelized by using multiple processes to compile the sources, the configuration step is largely single threaded. The multilib project has to build many variants now, and so a significant amount of time is spent waiting for the configuration of various projects to finish. This patch attempts to make the build process more efficient by running all the configuration steps for every variant subproject in parallel. The configuration/build steps in the underlying runtimes project are exposed, so that the higher level multilib project can invoke them as a single target. So instead of building each variant in turn, all the versions of compiler-rt are configured, then all versions are built, then all the C libraries are configured, and so on. This maximizes the amount of work that can be done at any given time. The build steps already benefit from parallelization: although built in series, each has the full number of available processes to use. However, at higher CPU counts there is an observable limit on how many processes each build can effectively use. So it may also be more efficient to instead run the build steps in parallel with a smaller number of proceses available to each. The option to control it (ENABLE_PARALLEL_LIB_BUILD) is OFF by default as which strategy is faster may come down to your available hardware, whereas ENABLE_PARALLEL_LIB_CONFIG should always be beneficial, so I've defaulted that to ON.
The 'newhdrgen' tool replaced it some time ago, and that's written in Python, so it doesn't need to be built separately with host tools at all. As of upstream commit e0ae7793fca0c78, the migration is complete, and the old C++ libc-hdrgen doesn't exist at all any more. So we need to stop trying to build it – it will break our builds when no such build target exists.
Testing the llvm-libc build after the previous commit, I found that the arm-multilib cmake script unconditionally tries to invoke build targets like `cxxlibs-configure` or `cxxlibs-build` in the individual library variant builds. Those targets don't exist in an llvm-libc build, because those set `"ENABLE_CXX_LIBS": "OFF"` in their per-variant JSON files. This commit applies the simplest possible fix: _make_ targets of those names in `arm-runtimes`, even if nothing is actually in them. Then invoking them from the higher-level build script is a NOP instead of a failure.
LLVM Embedded Toolchain for Arm is now Arm Toolchain for Embedded hosted at https://github.com/arm/arm-toolchain/tree/arm-software/arm-software/embedded
Change in question: #126168
As this repo is getting depreciated, pinning picolibc to a specific commit, as we don't want to keep fixing merge conflicts and other unforeseen issues.
…ke` (#642) The used copies are in `arm-runtimes` directory.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
16 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.