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.
The RISCVToolChain, which was removed in commit f8cb798,
used a different compiler-rt path relative to the resource-dir
when GCCInstallation was valid. However, this behavior was
unintentionally overridden when it was merged into the
BareMetal toolchain. This patch restores the correct path
handling logic.
After this fix -
With valid GCCInstallation
`<resource-dir>/<llvm-rel-ver>/lib/<target-triple>libclang_rt.builtins.a`
Without valid GCCInstallation
`<resource-dir>/<llvm-rel-ver>/lib/baremetal/libclang_rt.builtins-<target>.a`
This patch:
- Adds CXXStdlib, runtimelib defaults for riscv target to
BareMetal toolchain object.
- Set the unwindlib to None for riscv target to match the
behavior of RISCVToolChain.
- Removes call to RISCVToolChain object from llvm.
This PR is last patch in the series of patches of merging RISCVToolchain
object into BareMetal toolchain object.
RFC:
https://discourse.llvm.org/t/merging-riscvtoolchain-and-baremetal-toolchains/75524
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
Add support for `-u` option to force defined symbols. This option is
supported by both lld and gnuld.
This is done as a part of the effort to merge RISCVToolchain object into
BareMetal toolchain object.
This is the 4th 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.
Add support for `-u` option to force defined symbols. This option is
supported by both lld and gnuld.
This is done as a part of the effort to merge RISCVToolchain object into
BareMetal toolchain object.
This is the 4th 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 moves the CommonArgs utilities into a location visible by the
Frontend Drivers, so that the Frontend Drivers may share option parsing
code with the Compiler Driver. This is useful when the Frontend Drivers
would like to verify that their incoming options are well-formed and
also not reinvent the option parsing wheel.
We already see code in the Clang/Flang Drivers that is parsing and
verifying its incoming options. E.g. OPT_ffp_contract. This option is
parsed in the Compiler Driver, Clang Driver, and Flang Driver, all with
slightly different parsing code. It would be nice if the Frontend
Drivers were not required to duplicate this Compiler Driver code. That
way there is no/low maintenance burden on keeping all these parsing
functions in sync.
Along those lines, the Frontend Drivers will now have a useful mechanism
to verify their incoming options are well-formed. Currently, the
Frontend Drivers trust that the Compiler Driver is not passing back junk
in some cases. The Language Drivers may even accept junk with no error
at all. E.g.:
`clang -cc1 -mprefer-vector-width=junk test.c'
With this patch, we'll now be able to tighten up incomming options to
the Frontend drivers in a lightweight way.
---------
Co-authored-by: Cameron McInally <cmcinally@nvidia.com>
Co-authored-by: Shafik Yaghmour <shafik.yaghmour@intel.com>
These are identified by misc-include-cleaner. I've filtered out those
that break builds. Also, I'm staying away from llvm-config.h,
config.h, and Compiler.h, which likely cause platform- or
compiler-specific build failures.
This patch is the third step to extend the current multilib system to
support the selection of library variants which do not correspond to
existing command-line options.
Proposal can be found in
https://discourse.llvm.org/t/rfc-multilib-custom-flags/81058
The multilib mechanism supports libraries that target code generation or
language options such as --target, -mcpu, -mfpu, -mbranch-protection.
However, some library variants are particular to features that do not
correspond to any command-line options. Examples include variants for
multithreading and semihosting.
This work introduces a way to instruct the multilib system to consider
these features in library selection. This particular patch is comprised
of the core processing of these flags.
- Custom flags in the command-line are read and forwarded to the
multilib system. If multiple flag values are present for the same flag
declaration, the last one wins. Default flag values are inserted for
flag declarations for which no value was given.
- Feed `MacroDefines` back into the driver. Each item `<string>` in the
`MacroDefines` list is formatted as `-D<string>`.
Library variants should list their requirement on one or more custom
flags like they do for any other flag. The new command-line option is
passed as-is to the multilib system, therefore it should be listed in
the format `-fmultilib-flag=<str>`.
Moreover, a variant that does not specify a requirement on any
particular flag can be matched against any value of that flag.
If the user specifies `-fmultilib-flag=<name>` with a name that is
invalid, but close enough to any valid flag value name in terms of edit
distance, a suggesting error is shown:
```
error: unsupported option '-fmultilib-flag=invalidname'; did you mean '-fmultilib-flag=validname'?
```
The candidate with the smallest edit distance is chosen for the
suggestion, up to a certain maximum value (implementation detail), after
which a non-suggesting error is shown instead:
```
error: unsupported option '-fmultilib-flag=invalidname'
```
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.
because:
- This brings Clang in line with GCC for which this is the default for ARM
- It frees up a register, so performance increase, especially on Thumb/6-M
- It will decrease code size
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
