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
The new bare metal support only supports the single thread model. This causes
the builtin atomic functions (e.g.: __atomic_fetch_add) to not generate
thread-safe assembly for these operations, which breaks our firmware. We target
bare metal, and need to atomically modify variables in our interrupt routines,
and task threads.
Internally, the -mthread-model flag determines whether to lower or expand
atomic operations (see D4984).
This change removes the overridden thread model methods, and instead relies on
the base ToolChain class to validate the thread model (which already includes
logic to validate single thread model support). If the single thread model is
required, the -mthread-model flag will have to be provided.
As a workaround "-mthread-model posix" could be provided, but it only works due
to a bug in the validation of the -mthread-model flag (separate patch coming to
fix this).
https://reviews.llvm.org/D37493
Patch by: Ian Tessier!
llvm-svn: 312651
The baremetal test (r303873) has been added with expectance of very
specific -resource-dir. However, the test itself nor the BareMetal
driver does not enforce any specific -resource-dir, making this
constraint invalid. It already has been altered twice -- in r303910 for
Windows compatibility, and in r304085 for systems using lib64. To
account for even more systems, just use [[RESOURCE_DIR]] like a number
of other tests do. This is needed for Gentoo where RESOURCE_DIR starts
with ../ (uses relative path to a parent directory).
Differential Revision: https://reviews.llvm.org/D33877
llvm-svn: 304715
Also comes with a cmake cache for building the runtime bits:
$ cmake <normal cmake flags> \
-DBAREMETAL_ARMV6M_SYSROOT=/path/to/sysroot \
-DBAREMETAL_ARMV7M_SYSROOT=/path/to/sysroot \
-DBAREMETAL_ARMV7EM_SYSROOT=/path/to/sysroot \
-C /path/to/clang/cmake/caches/BaremetalARM.cmake \
/path/to/llvm
https://reviews.llvm.org/D33259
llvm-svn: 303873
Petr Hosek