This patch removes %T from clang lit tests. %T has been deprecated for
about seven years and is not reccomended as it is not unique to each
test, which can lead to races. This patch is intended to remove usage in
tree with the end goal of removing support for %T within lit.
Some tests in LLVM-libc require this flag
(https://github.com/llvm/llvm-project/issues/145349), which requires
compiler-rt to be linked in, but not the C library. With this change,
the `-nolibc` flag will not be ignored.
I'm unsure if there is an official source for which targets use/support
which emulations, but for the baremetal GNU Arm/AArch64 toolchains or
binutils builds I've tried to use, GNU ld either did not support the
Linux emulations (resulting in errors unless overriding the emulation)
or the Linux emulations were supported but GCC passed the non-Linux
emulations by default.
These emulations all seem to be accepted by lld as well, so try to align
with what it seems GCC is doing and prefer the non-Linux emulations for
baremetal Arm/AArch64 targets.
Commit 597ee88 moved the -X flag to a new position in the baremetal
toolchain's linker job, but unintentionally left the original instance in place.
This patch removes the redundant flag, ensuring -X is passed only once.
RISCVToolChain object passes `--sysroot` option from clang to gnuld.
Adding
the supprt for the same in BareMetal toolchain object.
This is done as a part of the effort to merge RISCVToolchain object into
BareMetal toolchain object.
This is the 5th patch in the series of patches for merging
RISCVToolchain object
into BareMetal toolchain object.
RFC:
https://discourse.llvm.org/t/merging-riscvtoolchain-and-baremetal-toolchains/75524
The linker job in BareMetal toolchain object will be used by GNU ld and
lld both.
However, gnuld process the arguments in the order in which they appear
on command
line, whereas there is no such restriction with lld.
The previous order was:
LibraryPaths -> Libraries -> LTOOptions -> LinkerInputs The new order
is:
LibraryPaths -> LTOOptions -> LinkerInputs -> Libraries
LTO options need to be added before adding any linker inputs because
file format
after compile stage during LTO is bitcode which gnuld natively cannot
process.
Hence will need to pass appropriate plugins before adding any bitcode
file on the
command line.
Object files that are getting linked need to be passed before processing
any
libraries so that gnuld can appropriately do symbol resolution for the
symbols
for which no definition is provided through user code.
Similar link order is also followed by other linker jobs for gnuld such
as in
gnutools::Linker in Gnu.cpp
This is the 3rd patch in the series of patches of merging RISCVToolchain
into
BareMetal toolchain object.
RFC:
https:
//discourse.llvm.org/t/merging-riscvtoolchain-and-baremetal-toolchains/75524
This patch conditionalise the addition of crt{begin,end}.o object files
along with addition of -lgloss lib based on whether libc selected is
newlib or
llvm libc. Since there is no way a user can specify which libc it wants
to
link against, currently passing valid GCCInstallation to driver will
select
newlib otherwise it will default to llvm libc.
Moreover, this patch makes gnuld the default linker for baremetal
toolchain object. User need to pass `-fuse-ld=lld` explicitly to driver
to select
lld
This is the 2nd patch in the series of patches of merging RISCVToolchain
into BareMetal toolchain object.
RFC:
https://discourse.llvm.org/t/merging-riscvtoolchain-and-baremetal-toolchains/75524
This patch introduces enhancements to the Baremetal toolchain to support
GCC toolchain detection.
- If the --gcc-install-dir or --gcc-toolchain options are provided and
point to valid paths, the sysroot is derived from those locations.
- If not, the logic falls back to the existing sysroot inference
mechanism already present in the Baremetal toolchain.
- Support for adding include paths for the libstdc++ library has also
been added.
Additionally, the restriction to always use the integrated assembler has
been removed. With a valid GCC installation, the GNU assembler can now
be used as well.
This patch currently updates and adds tests for the ARM target only.
RISC-V-specific tests will be introduced in a later patch, once the
RISCVToolChain is fully merged into the Baremetal toolchain. At this
stage, there is no way to test the RISC-V target within this PR.
RFC:
https://discourse.llvm.org/t/merging-riscvtoolchain-and-baremetal-toolchains/75524
This patch introduces enhancements to the Baremetal toolchain to support
GCC toolchain detection.
- If the --gcc-install-dir or --gcc-toolchain options are provided and
point to valid paths, the sysroot is derived from those locations.
- If not, the logic falls back to the existing sysroot inference
mechanism already present in the Baremetal toolchain.
- Support for adding include paths for the libstdc++ library has also
been added.
Additionally, the restriction to always use the integrated assembler has
been removed. With a valid GCC installation, the GNU assembler can now
be used as well.
This patch currently updates and adds tests for the ARM target only.
RISC-V-specific tests will be introduced in a later patch, once the
RISCVToolChain is fully merged into the Baremetal toolchain. At this
stage, there is no way to test the RISC-V target within this PR.
RFC:
https://discourse.llvm.org/t/merging-riscvtoolchain-and-baremetal-toolchains/75524
…Baremetal toolchain (#121829)"
This reverts the following stack of commits, due to them breaking the
Fuchsia toolchain and corresponding LLVM buildbot.
Revert "[Driver] Fix Arm/AArch64 Link Argument tests (#144582)" This
reverts commit a79186c1ea62bbe0579e0b1eed4ad507966cca41.
Revert "[Driver] Add option to force undefined symbols during linking in
BareMetal toolchain object. (#132807)" This reverts commit
9cb754509608b9d9143fa17f775631bbfcce0848.
Revert "[Driver] Fix link order of BareMetal toolchain object (#132806)"
This reverts commit 31523de4b000ca254259ae3167d28922e1302648.
Revert "[Driver] Add support for crtbegin.o, crtend.o and libgloss lib
to BareMetal toolchain object (#121830)" This reverts commit
ec230aa7a7d13c222c0b34b87c3c16937383b4a0.
Revert "[Driver] Add support for GCC installation detection in Baremetal
toolchain (#121829)" This reverts commit
eb31c422d0dc816bf285a81bf92690d4d16273ed.
The linker job in BareMetal toolchain object will be used by GNU ld and
lld both.
However, gnuld process the arguments in the order in which they appear
on command
line, whereas there is no such restriction with lld.
The previous order was:
LibraryPaths -> Libraries -> LTOOptions -> LinkerInputs
The new order is:
LibraryPaths -> LTOOptions -> LinkerInputs -> Libraries
LTO options need to be added before adding any linker inputs because
file format
after compile stage during LTO is bitcode which gnuld natively cannot
process.
Hence will need to pass appropriate plugins before adding any bitcode
file on the
command line.
Object files that are getting linked need to be passed before processing
any
libraries so that gnuld can appropriately do symbol resolution for the
symbols
for which no definition is provided through user code.
Similar link order is also followed by other linker jobs for gnuld such
as in
gnutools::Linker in Gnu.cpp
This is the 3rd patch in the series of patches of merging RISCVToolchain
into
BareMetal toolchain object.
RFC:
https://discourse.llvm.org/t/merging-riscvtoolchain-and-baremetal-toolchains/75524
This patch conditionalise the addition of crt{begin,end}.o object files
along
with addition of -lgloss lib based on whether libc selected is newlib or
llvm
libc. Since there is no way a user can specify which libc it wants to
link
against, currently passing valid GCCInstallation to driver will select
newlib
otherwise it will default to llvm libc.
Moreover, this patch makes gnuld the default linker for baremetal
toolchain
object. User need to pass `-fuse-ld=lld` explicitly to driver to select
lld
This is the 2nd patch in the series of patches of merging RISCVToolchain
into
BareMetal toolchain object.
RFC:
https://discourse.llvm.org/t/merging-riscvtoolchain-and-baremetal-toolchains/75524
This patch introduces enhancements to the Baremetal toolchain to support
GCC toolchain detection.
- If the --gcc-install-dir or --gcc-toolchain options are provided and
point to valid paths, the sysroot is derived from those locations.
- If not, the logic falls back to the existing sysroot inference
mechanism already present in the Baremetal toolchain.
- Support for adding include paths for the libstdc++ library has also
been added.
Additionally, the restriction to always use the integrated assembler has
been removed. With a valid GCC installation, the GNU assembler can now
be used as well.
This patch currently updates and adds tests for the ARM target only.
RISC-V-specific tests will be introduced in a later patch, once the
RISCVToolChain is fully merged into the Baremetal toolchain. At this
stage, there is no way to test the RISC-V target within this PR.
RFC:
https://discourse.llvm.org/t/merging-riscvtoolchain-and-baremetal-toolchains/75524
The handling of libc++ and other runtime libraries in the baremetal
driver is different from other targets for no particular reason. This
change removes the custom in the baremetal driver logic and replaces it
with the generic logic to improve consistency and reduce maintenance
overhead while also handling additional flags the current logic doesn't.
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.
BSD, Linux, and z/OS enable `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR` by
default.
When a compiler-rt library is not found, we currently report an
incorrect filename `libclang_rt.XXX-$arch.a`
```
% /tmp/Debug/bin/clang++ a.cc -fsanitize=address -o a
ld.lld: error: cannot open /tmp/Debug/lib/clang/19/lib/linux/libclang_rt.asan-x86_64.a: No such file or directory
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
```
With this change, we will correctly report:
```
% /tmp/Debug/bin/clang++ a.cc -fsanitize=address -o a
ld.lld: error: cannot open /tmp/Debug/lib/clang/19/lib/x86_64-unknown-linux-gnu/libclang_rt.asan.a: No such file or directory
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
```
Link: https://discourse.llvm.org/t/runtime-directory-fallback/76860
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.
If the path components of %clang contain a symlink, e.g.
```
% cd /tmp; ln -s Rel xxx
% /tmp/xxx/bin/clang --target=powerpc-unknown-eabi -xc /dev/null '-###'
InstalledDir: /tmp/xxx/bin
...
"-internal-isystem" "/tmp/Rel/bin/../lib/clang-runtimes/powerpc-unknown-eabi/include"
```
the test will fail. Such commands should use -no-canonical-prefixes, or
derive the include and library paths from cc1 -isysroot using driver
--sysroot.
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
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
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
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
* Remove -no-canonical-prefixes. See 980679981fbc311bc07f8cd23e3739fd56c22d2a
* Test a.out and %t.out in few tests and remove excess `-o %t.o`
* Avoid wrapping lines too aggresstively
* Replace `"{{[^"]*}}ld{{(\.(lld|bfd|gold))?}}{{(\.exe)?}}"` with `ld{{(.exe)?}}"`. The new pattern supports more CLANG_DEFAULT_LINKER.
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
A new check was added in 3b93dc68, which seems to not be possible to get
working correctly on windows systems:
The test first "captures" the install directory of the clang toolchain
running the test as follows:
// CHECK-AARCH64-NO-HOST-INC: InstalledDir: [[INSTALLEDDIR:.+]]
Then, in a check line a bit later, it uses this to check if a particular
directory in the toolchain installation directory is included when
targeting aarch64-none-elf:
// CHECK-AARCH64-NO-HOST-INC-SAME: "-internal-isystem" "[[INSTALLEDDIR]]{{[/\\]+}}..{{[/\\]+}}lib{{[/\\]+}}clang-runtimes{{[/\\]+}}aarch64-none-elf{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}v1"
Even though the test aims to take into account forward vs backward slash
differences between Windows and Unix paths, it still fails on Windows.
It seems that on Windows (this is based on the output log from a Windows
bot), the INSTALLEDDIR variable has the following value:
note: with "INSTALLEDDIR" equal to "c:\\\\b\\\\slave\\\\clang-x64-windows-msvc\\\\build\\\\stage1\\\\bin"
However the actual "InstalledDir:" output produced by the clang
toolchain on that Windows bot was:
InstalledDir: c:\b\slave\clang-x64-windows-msvc\build\stage1\bin
It is unclear where the explosion of backslashes happens. Maybe this is
a bug in FileCheck somewhere?
Anyway, marking this test as not supported on Windows to make the bots
green again.
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
Currently, support for the x32 ABI is handled as a multilib to the
x86_64 target only. However, full self-hosting x32 systems treating it
as a separate architecture with its own architecture triplets as well as
search paths exist as well, in Debian's x32 port and elsewhere.
This adds the missing architecture triplets and search paths so that
clang can work as a native compiler on x32, and updates the tests so
that they pass when using an x32 libdir suffix.
Additionally, we would previously also assume that objects from any
x86_64-linux-gnu GCC installation could be used to target x32. This
changes the logic so that only GCC installations that include x32
support are used when targetting x32, meaning x86_64-linux-gnux32 GCC
installations, and x86_64-linux-gnu and i686-linux-gnu GCC installations
that include x32 multilib support.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D52050
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
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
Baremetal toolchain is not adding sysroot/lib to the library
search path. This is forcing the user to do it manually. This commit
fixes this shortcoming by adding the sysroot/lib to library search path
if sysroot is not empty.
Reviewed By: jroelofs
Differential Revision: https://reviews.llvm.org/D91559
When the clang baremetal driver selects the rt.builtins static library
it prefix with "-l" and appends ".a". The result is a nonsense option
which lld refuses to accept.
Differential Revision: https://reviews.llvm.org/D73904
Change-Id: Ic753b6104e259fbbdc059b68fccd9b933092d828
LLVM triple normalization is handling "unknown" and empty components
differently; for example given "x86_64-unknown-linux-gnu" and
"x86_64-linux-gnu" which should be equivalent, triple normalization
returns "x86_64-unknown-linux-gnu" and "x86_64--linux-gnu". autoconf's
config.sub returns "x86_64-unknown-linux-gnu" for both
"x86_64-linux-gnu" and "x86_64-unknown-linux-gnu". This changes the
triple normalization to behave the same way, replacing empty triple
components with "unknown".
This addresses PR37129.
Differential Revision: https://reviews.llvm.org/D50219
llvm-svn: 339294
This test fails if clang is configure with, for example, gold as the
default linker. It does not appear that this test really relies on lld
so make the checks accept ld, ld.gold and ld.bfd too.
llvm-svn: 338290
