If `multilib.yaml` reports a custom error message for some unsupported
configuration, it's not very helpful to display that error message
_first_, and then follow it up with a huge list of all the multilib
configurations that _are_ supported.
In interactive use, the list is likely to scroll the most important
message off the top of the user's window, leaving them with just a
long list of available libraries, without a visible explanation of
_why_ clang just printed that long list. Also, in general, it makes
more intuitive sense to print the message last that shows why
compilation can't continue, because that's where users are most likely
to look for the reason why something stopped.
Since the introduction of the use of a YAML file to configure the
selection of multilibs for baremetal, the path for that file has been
hardcoded into the clang driver code. This makes it difficult to provide
any alternative configurations for multilib and, by consequence, impacts
the tetability of any changes related to it - e.g. the existing multilib
YAML tests currently rely on creating fake toolchain directories to
inject their own configuration files.
This change introduces a new command line option to the clang driver,
`--multi-lib-config=`, to enable the use of a custom path to be used
when loading the multilib YAML config file. It also updates the existing
multilib YAML tests to use the new option.
Sometimes a collection of multilibs has a gap in it, where a set of
driver command-line options can't work with any of the available
libraries.
For example, the Arm MVE extension requires special startup code (you
need to initialize FPSCR.LTPSIZE), and also benefits greatly from
-mfloat-abi=hard. So a multilib provider might build a library for
systems without MVE, and another for MVE with -mfloat-abi=hard,
anticipating that that's what most MVE users would want. But then if a
user compiles for MVE _without_ -mfloat-abi=hard, thhey can't use either
of those libraries – one has an ABI mismatch, and the other will fail to
set up LTPSIZE.
In that situation, it's useful to include a multilib.yaml entry for the
unworkable intermediate situation, and have it map to a fatal error
message rather than a set of actual libraries. Then the user gets a
build failure with a sensible explanation, instead of selecting an
unworkable library and silently generating bad output. The new
regression test demonstrates this case.
This patch introduces extra syntax into multilib.yaml, so that a record
in the `Variants` list can omit the `Dir` key, and in its place, provide
a `FatalError` key. Then, if that variant is selected, the error message
is emitted as a clang diagnostic, and multilib selection fails.
In order to emit the error message in `MultilibSet::select`, I had to
pass a `Driver &` to that function, which involved plumbing one through
to every call site, and in the unit tests, constructing one specially.
This changes the bare-metal driver logic such that it _always_ tries
multilib.yaml if it exists, and it falls back to the hardwired/default
RISC-V multilib selection only if a multilib.yaml doesn't exist. In
contrast, the current behavior is that RISC-V can never use
multilib.yaml, but other targets will try it if it exists.
The flags `-march=` and `-mabi=` are exposed for multilib.yaml to match
on. There is no attempt to help YAML file creators to duplicate the
existing hard-wired multilib reuse logic -- they will have to implement
it using `Mappings`.
This should be backwards-compatible with existing sysroots, as
multilib.yaml was previously never used for RISC-V, and the behavior
doesn't change after this PR if the file doesn't exist.
We want to support using a complete Clang/LLVM toolchain that includes
LLVM libc and libc++ for baremetal targets. To do so, we need the driver
to add the necessary include paths.
Pass the linker LTO options enabled by the clang '-flto' command line
options when targeting bare-metal.
---------
Co-authored-by: Keith Walker <keith.walker@arm.com>
The generic `tools::AddRunTimeLibs` uses an absolute path. Change
BareMetal to match.
I believe users are not supposed to place other files under the
directory containing `libclang_rt.builtins-$arch.a`. If they rely on the
implicit -L, they now need to explicitly specify -L.
In the case of -mno-relax option. Otherwise, we cannot prevent
relaxation if we split compilation and linking using Clang driver.
One can consider the following use case:
clang [...] -c -o myobject.o (just compile)
clang [...] myobject.o -o myobject.elf -mno-relax (linking)
In this case, myobject.elf will be relaxed, the -mno-relax will be
silently ignored.
When -nostdinc and -nostdinc++ are both specified and the Baremetal
toolchain is used, an unused command line argument warning for
-nostdinc++ is produced. This doesn't seem particularly meaningful as
-nostdinc++ would have been claimed/used had the check in
AddClangCXXStdlibIncludeArgs not short-circuited. So, just claim all
arguments in this check.
I believe this is consistent with what was done for the GNU toolchain
(see 6fe7de90b9e4e466a5c2baadafd5f72d3203651d), so hopefully this is
appropriate here as well.
Baremetal targets tend to implement their own runtime support for
sanitizers. Clang driver gatekeeping of allowed sanitizer types is
counter productive.
This change allows anything that does not crash and burn in compilation,
and leaves any potential runtime issues for the user to figure out.
-Z is an Apple ld64 option. ELF linkers don't recognize -Z, except
OpenBSD which patched GNU ld to add -Z for zmagic (seems unused)
> -Z Produce 'Standard' executables, disables Writable XOR Executable
features in resulting binaries.
Some `ToolChain`s have -Z due to copy-and-paste mistakes.
Most ArgList member functions use the modern functionName style while some like
AddAllArgs use the legacy FunctionName style. These uses are mostly linker
options which have been modified recently to fix duplicate -e issues, so just
update these call sites.
IsARMBIgEndian function returns true only if:
1. The triples are either arm or thumb and the
commandline has the option -mbig-endian
2. The triples are either armeb or thumbeb.
Missing the checking of arm or thumb triples in the
first case pass through the --be8 endian flag to
linker For AArch64 as well which is not expected.
This is the regression happened from the previous
patch https://reviews.llvm.org/D154786.
It is better to refactor to only call IsARMBigEndian
for isARM and isthumb satisfying conditions which
keeps ARM and AArch64 separate.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D155808
When linking a big-endian image for Arm, clang has
to select between BE8 and BE32 formats. The default
is dependent on the selected target architecture.
For ARMv6 and later architectures the default is
BE8, for older architectures the default is BE32.
For BE8 and BE32, compiler outputs a big endian ELF
relocatable object file with the instructions and
data both big endian. The difference is that at
link time, for BE8 a linker must endian reverse
the instructions to little endian. For BE8, the
clang has to pass --be8 to the linker for Arm.
At the moment clang is not passing the --be8 flag
to linker for the baremetal target architectures
above ArmV6 for Arm. This patch passes through --be8
and -BE or EL to the linker, taking into account the
target and the -mbig-endian and -mlittle-endian flag.
Also there are few more changes in the baremetal
driver so that the code can cope with AArch64 being
big-endian as well.
Reviewed By: michaelplatings, MaskRay
Differential Revision: https://reviews.llvm.org/D154786
This seems to match https://gcc.gnu.org/install/specific.html#powerpc-x-eabi
It seems that anything with OS `none` (although that doesn’t seem to be distinguished from `unknown`) or with environment `eabi` should be treated as bare-metal.
Since this seems to have been handled on a case-by-case basis in the past ([arm](https://reviews.llvm.org/D33259), [riscv](https://reviews.llvm.org/D91442), [aarch64](https://reviews.llvm.org/D111134)), what I am proposing here is to add another case to the list to also handle `powerpc[64][le]-unknown-unknown-eabi` using the `BareMetal` toolchain, following the example of the existing cases. (We don’t care about powerpc64 and powerpc[64]le, but it seemed appropriate to lump them in.)
At Indel, we have been building bare-metal embedded applications that run on custom PowerPC and ARM systems with Clang and LLD for a couple of years now, using target triples `powerpc-indel-eabi`, `powerpc-indel-eabi750`, `arm-indel-eabi`, `aarch64-indel-eabi` (which I just learned from D153430 is wrong and should be `aarch64-indel-elf` instead, but that’s a different matter). This has worked fine for ARM, but for PowerPC we have been unable to call the linker (LLD) through the Clang driver, because it would insist on calling GCC as the linker, even when told `-fuse-ld=lld`. That does not work for us, there is no GCC around. Instead we had to call `ld.lld` directly, introducing some special cases in our build system to translate between linker-via-driver and linker-called-directly command line arguments. I have now dug into why that is, and found that the difference between ARM and PowerPC is that `arm-indel-eabi` hits a special case that causes the Clang driver to instantiate a `BareMetal` toolchain that is able to call LLD and works the way we need, whereas `powerpc-indel-eabi` lands in the default case of a `Generic_ELF` (subclass of `Generic_GCC`) toolchain which expects GCC.
Reviewed By: MaskRay, michaelplatings, #powerpc, nemanjai
Differential Revision: https://reviews.llvm.org/D154357
In preparation for removing the `#include "llvm/ADT/StringExtras.h"`
from the header to source file of `llvm/Support/Error.h`, first add in
all the missing includes that were previously included transitively
through this header.
This is fixing all files missed in b0abd4893fa1.
Differential Revision: https://reviews.llvm.org/D154543
-e has the LinkerInput flag (commit fcf8ada18f9cfb1261262e4b0399ae9ab40451f8)
and is rendered by AddLinkerInputs. We should remove duplicate rendering (e.g.,
`Args.AddAllArgs(CmdArgs, options::OPT_e)`).
The error could be awkward to work around when experimenting with flags
that didn't have a matching multilib. It also broke many tests when
multilib.yaml was present in the build directory.
Reviewed By: simon_tatham, MaskRay
Differential Revision: https://reviews.llvm.org/D153885
Previously if no matching multilib was found then the user would
typically see an error like "fatal error: 'stdio.h' file not found"
which gives no indication as to the underlying problem.
With this change the user will instead see an error like
clang: error: no multilib found matching flags: --target=thumbv7em-none-unknown-eabi -march=...
clang: note: available multilibs are:
--target=armv4t-none-unknown-eabi
--target=thumbv6m-none-unknown-eabi -mfpu=none
...
Differential Revision: https://reviews.llvm.org/D153292
This enables layering baremetal multilibs on top of each other.
For example a multilib containing only a no-exceptions libc++ could be
layered on top of a multilib containing C libs. This avoids the need
to duplicate the C library for every libc++ variant.
Differential Revision: https://reviews.llvm.org/D143075
This will enable layering multilibs on top of each other.
For example a multilib containing only a no-exceptions libc++ could be
layered on top of a multilib containing C libs. This avoids the need
to duplicate the C library for every libc++ variant.
This change doesn't expose the functionality externally, it only opens
the functionality up to be potentially used by ToolChain classes.
Differential Revision: https://reviews.llvm.org/D143059
The default location for multilib.yaml is lib/clang-runtimes, without
any target-specific suffix. This will allow multilibs for different
architectures to share a common include directory.
To avoid breaking the arm-execute-only.c CHECK-NO-EXECUTE-ONLY-ASM
test, add a ForMultilib argument to getARMTargetFeatures.
Since the presence of multilib.yaml can change the exact location of a
library, relax the baremetal.cpp test.
Differential Revision: https://reviews.llvm.org/D142986
Decouple the interface of the MultilibBuilder flag method from how flags
are stored internally. Likewise change the addMultilibFlag function.
Currently a multilib flag like "-fexceptions" means a multilib is
*incompatible* with the -fexceptions command line option, which is
counter-intuitive. This change is a step towards changing this scheme.
Differential Revision: https://reviews.llvm.org/D151437
According to the GNU ld manual
https://sourceware.org/binutils/docs/ld/ARM.html#ARM the R_ARM_TARGET2
relocation (used in exception handling tables) is treated differently
depending on the target. By default, LLD treats R_ARM_TARGET2 as
R_ARM_GOT_PREL (--target2=got-rel), which is correct for Linux but not
for embedded targets.
This patch adds --target2=rel to linker options in the baremetal
toolchain driver so that on baremetal targets, R_ARM_TARGET2 is
treated as R_ARM_REL32. Such behavior is compatible with GNU ld and
unwinding libraries (e.g., libuwind).
Reviewed By: peter.smith, phosek
Differential Revision: https://reviews.llvm.org/D149458
All officially supported linkers should support response files and
this avoids issues when compiling on platforms such as Windows.
Differential Revision: https://reviews.llvm.org/D148760
The functionality in MultilibSet for creating it is tied to its current
implementation. Putting that code in a separate class is an enabler for
changing the MultilibSet implementation.
Differential Revision: https://reviews.llvm.org/D142893
If you build compiler-rt with LLVM_ENABLE_PER_TARGET_RUNTIME_DIR then
the library filename will be "libclang_rt.builtins.a" instead of
"libclang_rt.builtins-<ARCH>.a"
The ToolChain::getCompilerRT method uses the "libclang_rt.builtins.a"
name if it can find the file in the library directories. If it can't
then it falls back to using "libclang_rt.builtins-<ARCH>.a". This
change adds the library directory such that "libclang_rt.builtins.a"
can be found.
Differential Revision: https://reviews.llvm.org/D139822
Currently baremetal driver adds <sysroot>/include/c++/v1
for libc++ headers. However on ChromeOS, all include files
are inside <sysroot>/usr/include. So add
<sysroot>/usr/include/c++/v1 if it exists in baremetal driver.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D134478
Refactor baremetal driver code to reduce the bespoke
additions and base class overrides.
This lets us use the per target runtimes like other clang
targets. E.g. clang -target armv7m-cros-none-eabi will now
be able to use the runtimes installed at
<resource_dir>/lib/armv7m-cros-none-eabi instead of the hardcoded
path <resource_dir>/lib/baremetal.
The older code paths should still continue to work as before if
<resource_dir>/lib/<tuple> does not exist.
Reviewed By: MaskRay, barannikov88
Differential Revision: https://reviews.llvm.org/D131225
Based on the discussion at [1], this patch adds a Clang flag called
-fexperimental-library that controls whether experimental library
features are provided in libc++. In essence, it links against the
experimental static archive provided by libc++ and defines a feature
that can be picked up by libc++ to enable experimental features.
This ensures that users don't start depending on experimental
(and hence unstable) features unknowingly.
[1]: https://discourse.llvm.org/t/rfc-a-compiler-flag-to-enable-experimental-unstable-language-and-library-features
Differential Revision: https://reviews.llvm.org/D121141
Moving `InputInfo.h` from `lib/Driver/` into `include/Driver` to be able to expose it in an API consumed from outside of `clangDriver`.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D106787
This addresses an issue introduced in D91559. We would invoke the
compiler with -Lpath/to/lib --sysroot=path/to/sysroot where both
locations contain libraries with the same name, but we expect linker
to pick up the library in path/to/lib since that version is more
specialized. This was the case before D91559 where the sysroot path
would be ignored, but after that change linker would now pick up the
library from the sysroot which resulted in unexpected behavior.
The sysroot path should always come after any user provided library
paths, followed by compiler runtime paths. We want for libraries in user
provided library paths to always take precedence over sysroot libraries.
This matches the behavior of other toolchains used with other targets.
Differential Revision: https://reviews.llvm.org/D102049
This addresses an issue introduced in D91559. We would invoke the
compiler with -Lpath/to/lib --sysroot=path/to/sysroot where both
locations contain libraries with the same name, but we expect linker
to pick up the library in path/to/lib since that version is more
specialized. This was the case before D91559 where the sysroot path
would be ignored, but after that change linker would now pick up the
library from the sysroot which resulted in unexpected behavior.
The sysroot path should always come after any user provided library
paths, followed by compiler runtime paths. We want for libraries in user
provided library paths to always take precedence over sysroot libraries.
This matches the behavior of other toolchains used with other targets.
Differential Revision: https://reviews.llvm.org/D102049
When targeting a MSVC triple, --dependant-libs with the name of the clang runtime library for profiling is added to the command line args. In it's current implementations clang_rt.profile-<ARCH> is chosen as the name. When building a distribution using LLVM_ENABLE_PER_TARGET_RUNTIME_DIR this fails, due to the runtime file names not having an architecture suffix in the filename.
This patch refactors getCompilerRT and getCompilerRTBasename to always consider per-target runtime directories. getCompilerRTBasename now simply returns the filename component of the path found by getCompilerRT
Differential Revision: https://reviews.llvm.org/D96638
This patch add support of riscv multilibs in the Baremetal toolchain. It is
a bit different to what is done in GNU.cpp as we are not iterating a
GNU sysroot to find the multilibs. This is intended for an llvm only
toolchain. We are not checking for the presence of any runtime bits to
enable a specific multilib.
I have structured the patch so that other targets for which
there is no multilibs support yet in Baremetal.cpp (e.g. arm-none-eabi)
will not be affected. Patch also allows some multilibs reuse.
Long term, I would like to go in the direction of data-driven specification of
multilib directories and flags.
Reviewed By: jroelofs
Differential Revision: https://reviews.llvm.org/D93138
Currently, Baremetal toolchain requires user to pass a sysroot location
using a --sysroot flag. This is not very convenient for the user. It also
creates problem for toolchain vendors who don't have a fixed location to
put the sysroot bits.
Clang does provide 'DEFAULT_SYSROOT' which can be used by the toolchain
builder to provide the default location. But it does not work if toolchain
is targeting multiple targets e.g. arm-none-eabi/riscv64-unknown-elf which
clang is capable of doing.
This patch tries to solve this problem by providing a default location of
the toolchain if user does not explicitly provides --sysroot. The exact
location and name can be different but it should fulfill these conditions:
1. The sysroot path should have a target triple element so that multi-target
toolchain problem (as I described above) could be addressed.
2. The location should not be $TOP/$Triple as this is used by gcc generally
and will be a problem for installing both gcc and clang based toolchain at
the same location.
Reviewed By: jroelofs
Differential Revision: https://reviews.llvm.org/D92677
Baremetal toolchain add Driver.SysRoot/include to the system include
paths without checking if Driver.SysRoot is empty. This resulted in
"-internal-isystem" "include" in the command. This patch adds check for
empty sysroot.
Reviewed By: jroelofs
Differential Revision: https://reviews.llvm.org/D92176
I am working on a baremetal riscv toolchain using LLVM runtime and
LLD linker. Baremetal.cpp provides most of the things needed for such
toolchain. So I have modified it to also handle riscv64/32-unknown-elf
targets alongside arm-none-eabi.
Currently, targets like riscv64-unknown-elf are handled by RISCVToolChain
which mostly expects a gcc toolchain to be present. If you dont
want the dependency on gcc-toolchain/libgloss or want to use LLD, then
RISCVToolChain is not a good fit.
So in the toolchain selection code, I have made this dependency of
RISCVToolChain on gcc toolchain explicit. It is created if gcc-toolchain
option is present. Otherwise Baremetal toolchain is created. I will be
happy to hear if there is a better way to choose between these two
toolchains.
Reviewed By: jroelofs
Differential Revision: https://reviews.llvm.org/D91442
