maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Driver/baremetal.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

358 lines
21 KiB
C++
Raw Normal View History

Don't defer to the GCC driver for linking arm-baremetal 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
2017-05-25 23:42:13 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: -target armv6m-none-eabi \
// RUN: -T semihosted.lds \
// RUN: -L some/directory/user/asked/for \
// RUN: --sysroot=%S/Inputs/baremetal_arm \
// RUN: | FileCheck --check-prefix=CHECK-V6M-C %s
[ADT] Normalize empty triple components 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
2018-08-09 06:23:57 +08:00
// CHECK-V6M-C: "[[PREFIX_DIR:.*]]{{[/\\]+}}{{[^/^\\]+}}{{[/\\]+}}clang{{.*}}" "-cc1" "-triple" "thumbv6m-none-unknown-eabi"
[test] Fix baremetal test to allow any -resource-dir 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
2017-06-05 22:13:37 +08:00
// CHECK-V6M-C-SAME: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
Don't defer to the GCC driver for linking arm-baremetal 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
2017-05-25 23:42:13 +08:00
// CHECK-V6M-C-SAME: "-isysroot" "[[SYSROOT:[^"]*]]"
Make test/Driver/baremetal.cpp pass on Windows llvm-svn: 303910
2017-05-26 04:39:52 +08:00
// CHECK-V6M-C-SAME: "-internal-isystem" "[[SYSROOT]]{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}v1"
// CHECk-V6M-C-SAME: "-internal-isystem" "[[SYSROOT]]{{[/\\]+}}include"
Don't defer to the GCC driver for linking arm-baremetal 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
2017-05-25 23:42:13 +08:00
// CHECK-V6M-C-SAME: "-x" "c++" "{{.*}}baremetal.cpp"
Make test/Driver/baremetal.cpp work with linkers other than lld 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
2018-07-31 03:08:20 +08:00
// CHECK-V6M-C-NEXT: "{{[^"]*}}ld{{(\.(lld|bfd|gold))?}}{{(\.exe)?}}" "{{.*}}.o" "-Bstatic"
Make test/Driver/baremetal.cpp pass on Windows llvm-svn: 303910
2017-05-26 04:39:52 +08:00
// CHECK-V6M-C-SAME: "-T" "semihosted.lds" "-Lsome{{[/\\]+}}directory{{[/\\]+}}user{{[/\\]+}}asked{{[/\\]+}}for"
[BareMetal] Ensure that sysroot always comes after library paths 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
2021-05-07 14:05:39 +08:00
// CHECK-V6M-C-SAME: "-L[[SYSROOT:[^"]+]]{{[/\\]+}}lib"
// CHECK-V6M-C-SAME: "-L[[RESOURCE_DIR:[^"]+]]{{[/\\]+}}lib{{[/\\]+}}baremetal"
[clang] stop baremetal driver to append .a to lib 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
2020-02-13 19:08:46 +08:00
// CHECK-V6M-C-SAME: "-lc" "-lm" "-lclang_rt.builtins-armv6m"
Don't defer to the GCC driver for linking arm-baremetal 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
2017-05-25 23:42:13 +08:00
// CHECK-V6M-C-SAME: "-o" "{{.*}}.o"
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: -target armv6m-none-eabi \
// RUN: -nostdlibinc -nobuiltininc \
// RUN: --sysroot=%S/Inputs/baremetal_arm \
// RUN: | FileCheck --check-prefix=CHECK-V6M-LIBINC %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: -target armv6m-none-eabi \
// RUN: -nostdinc \
// RUN: --sysroot=%S/Inputs/baremetal_arm \
// RUN: | FileCheck --check-prefix=CHECK-V6M-LIBINC %s
// CHECK-V6M-LIBINC-NOT: "-internal-isystem"
// RUN: %clangxx -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: -target armv6m-none-eabi \
// RUN: --sysroot=%S/Inputs/baremetal_arm \
// RUN: | FileCheck --check-prefix=CHECK-V6M-DEFAULTCXX %s
[Driver] Fix architecture triplets and search paths for Linux x32 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
2021-04-01 16:47:56 +08:00
// CHECK-V6M-DEFAULTCXX: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
Make test/Driver/baremetal.cpp work with linkers other than lld 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
2018-07-31 03:08:20 +08:00
// CHECK-V6M-DEFAULTCXX: "{{[^"]*}}ld{{(\.(lld|bfd|gold))?}}{{(\.exe)?}}" "{{.*}}.o" "-Bstatic"
Add sysroot/lib to library search path of baremetal toolchain. 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
2020-11-18 20:16:40 +08:00
// CHECK-V6M-DEFAULTCXX-SAME: "-L{{[^"]*}}{{[/\\]+}}Inputs{{[/\\]+}}baremetal_arm{{[/\\]+}}lib"
[BareMetal] Ensure that sysroot always comes after library paths 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
2021-05-07 14:05:39 +08:00
// CHECK-V6M-DEFAULTCXX-SAME: "-L[[RESOURCE_DIR]]{{[/\\]+}}lib{{[/\\]+}}baremetal"
Don't defer to the GCC driver for linking arm-baremetal 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
2017-05-25 23:42:13 +08:00
// CHECK-V6M-DEFAULTCXX-SAME: "-lc++" "-lc++abi" "-lunwind"
[clang] stop baremetal driver to append .a to lib 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
2020-02-13 19:08:46 +08:00
// CHECK-V6M-DEFAULTCXX-SAME: "-lc" "-lm" "-lclang_rt.builtins-armv6m"
Don't defer to the GCC driver for linking arm-baremetal 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
2017-05-25 23:42:13 +08:00
// CHECK-V6M-DEFAULTCXX-SAME: "-o" "{{.*}}.o"
// RUN: %clangxx -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: -target armv6m-none-eabi \
// RUN: --sysroot=%S/Inputs/baremetal_arm \
// RUN: -stdlib=libc++ \
// RUN: | FileCheck --check-prefix=CHECK-V6M-LIBCXX %s
[Driver] Fix architecture triplets and search paths for Linux x32 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
2021-04-01 16:47:56 +08:00
// CHECK-V6M-LIBCXX: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
Make test/Driver/baremetal.cpp pass on Windows llvm-svn: 303910
2017-05-26 04:39:52 +08:00
// CHECK-V6M-LIBCXX-NOT: "-internal-isystem" "{{[^"]+}}{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}{{[^v].*}}"
[Driver] Fix architecture triplets and search paths for Linux x32 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
2021-04-01 16:47:56 +08:00
// CHECK-V6M-LIBCXX-SAME: "-internal-isystem" "{{[^"]+}}{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}v1"
Make test/Driver/baremetal.cpp work with linkers other than lld 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
2018-07-31 03:08:20 +08:00
// CHECK-V6M-LIBCXX: "{{[^"]*}}ld{{(\.(lld|bfd|gold))?}}{{(\.exe)?}}" "{{.*}}.o" "-Bstatic"
Add sysroot/lib to library search path of baremetal toolchain. 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
2020-11-18 20:16:40 +08:00
// CHECK-V6M-LIBCXX-SAME: "-L{{[^"]*}}{{[/\\]+}}Inputs{{[/\\]+}}baremetal_arm{{[/\\]+}}lib"
[BareMetal] Ensure that sysroot always comes after library paths 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
2021-05-07 14:05:39 +08:00
// CHECK-V6M-LIBCXX-SAME: "-L[[RESOURCE_DIR]]{{[/\\]+}}lib{{[/\\]+}}baremetal"
Don't defer to the GCC driver for linking arm-baremetal 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
2017-05-25 23:42:13 +08:00
// CHECK-V6M-LIBCXX-SAME: "-lc++" "-lc++abi" "-lunwind"
[clang] stop baremetal driver to append .a to lib 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
2020-02-13 19:08:46 +08:00
// CHECK-V6M-LIBCXX-SAME: "-lc" "-lm" "-lclang_rt.builtins-armv6m"
Don't defer to the GCC driver for linking arm-baremetal 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
2017-05-25 23:42:13 +08:00
// CHECK-V6M-LIBCXX-SAME: "-o" "{{.*}}.o"
// RUN: %clangxx -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: -target armv6m-none-eabi \
// RUN: --sysroot=%S/Inputs/baremetal_arm \
// RUN: -stdlib=libstdc++ \
// RUN: | FileCheck --check-prefix=CHECK-V6M-LIBSTDCXX %s
[Driver] Fix architecture triplets and search paths for Linux x32 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
2021-04-01 16:47:56 +08:00
// CHECK-V6M-LIBSTDCXX: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
Make test/Driver/baremetal.cpp pass on Windows llvm-svn: 303910
2017-05-26 04:39:52 +08:00
// CHECK-V6M-LIBSTDCXX-NOT: "-internal-isystem" "{{[^"]+}}{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}v1"
[Driver] Fix architecture triplets and search paths for Linux x32 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
2021-04-01 16:47:56 +08:00
// CHECK-V6M-LIBSTDCXX-SAME: "-internal-isystem" "{{[^"]+}}{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}6.0.0"
Make test/Driver/baremetal.cpp work with linkers other than lld 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
2018-07-31 03:08:20 +08:00
// CHECK-V6M-LIBSTDCXX: "{{[^"]*}}ld{{(\.(lld|bfd|gold))?}}{{(\.exe)?}}" "{{.*}}.o" "-Bstatic"
Add sysroot/lib to library search path of baremetal toolchain. 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
2020-11-18 20:16:40 +08:00
// CHECK-V6M-LIBSTDCXX-SAME: "-L{{[^"]*}}{{[/\\]+}}Inputs{{[/\\]+}}baremetal_arm{{[/\\]+}}lib"
[BareMetal] Ensure that sysroot always comes after library paths 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
2021-05-07 14:05:39 +08:00
// CHECK-V6M-LIBSTDCXX-SAME: "-L[[RESOURCE_DIR]]{{[/\\]+}}lib{{[/\\]+}}baremetal"
Don't defer to the GCC driver for linking arm-baremetal 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
2017-05-25 23:42:13 +08:00
// CHECK-V6M-LIBSTDCXX-SAME: "-lstdc++" "-lsupc++" "-lunwind"
[clang] stop baremetal driver to append .a to lib 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
2020-02-13 19:08:46 +08:00
// CHECK-V6M-LIBSTDCXX-SAME: "-lc" "-lm" "-lclang_rt.builtins-armv6m"
Don't defer to the GCC driver for linking arm-baremetal 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
2017-05-25 23:42:13 +08:00
// CHECK-V6M-LIBSTDCXX-SAME: "-o" "{{.*}}.o"
// RUN: %clangxx -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: -target armv6m-none-eabi \
// RUN: --sysroot=%S/Inputs/baremetal_arm \
// RUN: -nodefaultlibs \
// RUN: | FileCheck --check-prefix=CHECK-V6M-NDL %s
[Driver] Fix architecture triplets and search paths for Linux x32 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
2021-04-01 16:47:56 +08:00
// CHECK-V6M-NDL: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
Make test/Driver/baremetal.cpp work with linkers other than lld 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
2018-07-31 03:08:20 +08:00
// CHECK-V6M-NDL: "{{[^"]*}}ld{{(\.(lld|bfd|gold))?}}{{(\.exe)?}}" "{{.*}}.o" "-Bstatic"
[BareMetal] Ensure that sysroot always comes after library paths 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
2021-05-07 14:05:39 +08:00
// CHECK-V6M-NDL-SAME: "-L{{[^"]*}}{{[/\\]+}}Inputs{{[/\\]+}}baremetal_arm{{[/\\]+}}lib"
[Driver] Fix architecture triplets and search paths for Linux x32 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
2021-04-01 16:47:56 +08:00
// CHECK-V6M-NDL-SAME: "-L[[RESOURCE_DIR]]{{[/\\]+}}lib{{[/\\]+}}baremetal"
[BareMetal] Ensure that sysroot always comes after library paths 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
2021-05-07 14:05:39 +08:00
// CHECK-V6M-NDL-SAME: "-o" "{{.*}}.o"
Don't defer to the GCC driver for linking arm-baremetal 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
2017-05-25 23:42:13 +08:00
// RUN: %clangxx -target arm-none-eabi -v 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-THREAD-MODEL
Fix ARM bare metal driver to support atomics 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
2017-09-07 01:09:25 +08:00
// CHECK-THREAD-MODEL: Thread model: posix
// RUN: %clangxx -target arm-none-eabi -mthread-model single -v 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-THREAD-MODEL-SINGLE
// CHECK-THREAD-MODEL-SINGLE: Thread model: single
// RUN: %clangxx -target arm-none-eabi -mthread-model posix -v 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-THREAD-MODEL-POSIX
// CHECK-THREAD-MODEL-POSIX: Thread model: posix
Extending Baremetal toolchain's support for the rtlib option. Differential Revision: https://reviews.llvm.org/D87164 Patch by Manuel Carrasco!
2020-09-18 23:47:37 +08:00
// RUN: %clang -### -target arm-none-eabi -rtlib=libgcc -v %s 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-RTLIB-GCC
// CHECK-RTLIB-GCC: -lgcc
[clang][Driver] Handle risvc in Baremetal.cpp. 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
2020-11-26 19:31:45 +08:00
Don't use sysroot/include when sysroot is empty. 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
2020-12-05 01:45:04 +08:00
// RUN: %clang -### -target arm-none-eabi -v %s 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-SYSROOT-INC
// CHECK-SYSROOT-INC-NOT: "-internal-isystem" "include"
[clang][Driver] Handle risvc in Baremetal.cpp. 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
2020-11-26 19:31:45 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: -target riscv64-unknown-elf \
// RUN: -L some/directory/user/asked/for \
// RUN: --sysroot=%S/Inputs/basic_riscv64_tree/riscv64-unknown-elf \
// RUN: | FileCheck --check-prefix=CHECK-RV64 %s
// CHECK-RV64: "[[PREFIX_DIR:.*]]{{[/\\]+}}{{[^/^\\]+}}{{[/\\]+}}clang{{.*}}" "-cc1" "-triple" "riscv64-unknown-unknown-elf"
// CHECK-RV64-SAME: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
// CHECK-RV64-SAME: "-isysroot" "[[SYSROOT:[^"]*]]"
// CHECK-RV64-SAME: "-internal-isystem" "[[SYSROOT]]{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}v1"
// CHECk-RV64-SAME: "-internal-isystem" "[[SYSROOT]]{{[/\\]+}}include"
// CHECK-RV64-SAME: "-x" "c++" "{{.*}}baremetal.cpp"
// CHECK-RV64-NEXT: "{{[^"]*}}ld{{(\.(lld|bfd|gold))?}}{{(\.exe)?}}" "{{.*}}.o" "-Bstatic"
// CHECK-RV64-SAME: "-Lsome{{[/\\]+}}directory{{[/\\]+}}user{{[/\\]+}}asked{{[/\\]+}}for"
[BareMetal] Ensure that sysroot always comes after library paths 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
2021-05-07 14:05:39 +08:00
// CHECK-RV64-SAME: "-L[[SYSROOT:[^"]+]]{{[/\\]+}}lib"
// CHECK-RV64-SAME: "-L[[RESOURCE_DIR:[^"]+]]{{[/\\]+}}lib{{[/\\]+}}baremetal"
[clang][Driver] Handle risvc in Baremetal.cpp. 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
2020-11-26 19:31:45 +08:00
// CHECK-RV64-SAME: "-lc" "-lm" "-lclang_rt.builtins-riscv64"
// CHECK-RV64-SAME: "-o" "{{.*}}.o"
// RUN: %clangxx -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: -target riscv64-unknown-elf \
// RUN: --sysroot=%S/Inputs/basic_riscv64_tree/riscv64-unknown-elf \
// RUN: | FileCheck --check-prefix=CHECK-RV64-DEFAULTCXX %s
[Driver] Fix architecture triplets and search paths for Linux x32 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
2021-04-01 16:47:56 +08:00
// CHECK-RV64-DEFAULTCXX: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
[clang][Driver] Handle risvc in Baremetal.cpp. 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
2020-11-26 19:31:45 +08:00
// CHECK-RV64-DEFAULTCXX: "{{[^"]*}}ld{{(\.(lld|bfd|gold))?}}{{(\.exe)?}}" "{{.*}}.o" "-Bstatic"
// CHECK-RV64-DEFAULTCXX-SAME: "-L{{[^"]*}}{{[/\\]+}}Inputs{{[/\\]+}}basic_riscv64_tree{{[/\\]+}}riscv64-unknown-elf{{[/\\]+}}lib"
[BareMetal] Ensure that sysroot always comes after library paths 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
2021-05-07 14:05:39 +08:00
// CHECK-RV64-DEFAULTCXX-SAME: "-L[[RESOURCE_DIR]]{{.*}}{{[/\\]+}}lib{{[/\\]+}}baremetal"
[clang][Driver] Handle risvc in Baremetal.cpp. 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
2020-11-26 19:31:45 +08:00
// CHECK-RV64-DEFAULTCXX-SAME: "-lc++" "-lc++abi" "-lunwind"
// CHECK-RV64-DEFAULTCXX-SAME: "-lc" "-lm" "-lclang_rt.builtins-riscv64"
// CHECK-RV64-DEFAULTCXX-SAME: "-o" "{{.*}}.o"
// RUN: %clangxx -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: -target riscv64-unknown-elf \
// RUN: --sysroot=%S/Inputs/basic_riscv64_tree/riscv64-unknown-elf \
// RUN: -stdlib=libc++ \
// RUN: | FileCheck --check-prefix=CHECK-RV64-LIBCXX %s
[Driver] Fix architecture triplets and search paths for Linux x32 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
2021-04-01 16:47:56 +08:00
// CHECK-RV64-LIBCXX: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
[clang][Driver] Handle risvc in Baremetal.cpp. 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
2020-11-26 19:31:45 +08:00
// CHECK-RV64-LIBCXX-NOT: "-internal-isystem" "{{[^"]+}}{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}{{[^v].*}}"
[Driver] Fix architecture triplets and search paths for Linux x32 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
2021-04-01 16:47:56 +08:00
// CHECK-RV64-LIBCXX-SAME: "-internal-isystem" "{{[^"]+}}{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}v1"
[clang][Driver] Handle risvc in Baremetal.cpp. 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
2020-11-26 19:31:45 +08:00
// CHECK-RV64-LIBCXX: "{{[^"]*}}ld{{(\.(lld|bfd|gold))?}}{{(\.exe)?}}" "{{.*}}.o" "-Bstatic"
// CHECK-RV64-LIBCXX-SAME: "-L{{[^"]*}}{{[/\\]+}}Inputs{{[/\\]+}}basic_riscv64_tree{{[/\\]+}}riscv64-unknown-elf{{[/\\]+}}lib"
[BareMetal] Ensure that sysroot always comes after library paths 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
2021-05-07 14:05:39 +08:00
// CHECK-RV64-LIBCXX-SAME: "-L[[RESOURCE_DIR]]{{[/\\]+}}lib{{[/\\]+}}baremetal"
[clang][Driver] Handle risvc in Baremetal.cpp. 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
2020-11-26 19:31:45 +08:00
// CHECK-RV64-LIBCXX-SAME: "-lc++" "-lc++abi" "-lunwind"
// CHECK-RV64-LIBCXX-SAME: "-lc" "-lm" "-lclang_rt.builtins-riscv64"
// CHECK-RV64-LIBCXX-SAME: "-o" "{{.*}}.o"
// RUN: %clangxx -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: -target riscv64-unknown-elf \
// RUN: --sysroot=%S/Inputs/basic_riscv64_tree/riscv64-unknown-elf \
// RUN: -stdlib=libstdc++ \
// RUN: | FileCheck --check-prefix=CHECK-RV64-LIBSTDCXX %s
[Driver] Fix architecture triplets and search paths for Linux x32 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
2021-04-01 16:47:56 +08:00
// CHECK-RV64-LIBSTDCXX: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
[clang][Driver] Handle risvc in Baremetal.cpp. 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
2020-11-26 19:31:45 +08:00
// CHECK-RV64-LIBSTDCXX-NOT: "-internal-isystem" "{{[^"]+}}{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}v1"
[Driver] Fix architecture triplets and search paths for Linux x32 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
2021-04-01 16:47:56 +08:00
// CHECK-RV64-LIBSTDCXX-SAME: "-internal-isystem" "{{[^"]+}}{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}8.0.1"
[clang][Driver] Handle risvc in Baremetal.cpp. 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
2020-11-26 19:31:45 +08:00
// CHECK-RV64-LIBSTDCXX: "{{[^"]*}}ld{{(\.(lld|bfd|gold))?}}{{(\.exe)?}}" "{{.*}}.o" "-Bstatic"
// CHECK-RV64-LIBSTDCXX-SAME: "-L{{[^"]*}}{{[/\\]+}}Inputs{{[/\\]+}}basic_riscv64_tree{{[/\\]+}}riscv64-unknown-elf{{[/\\]+}}lib"
[BareMetal] Ensure that sysroot always comes after library paths 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
2021-05-07 14:05:39 +08:00
// CHECK-RV64-LIBSTDCXX-SAME: "-L[[RESOURCE_DIR]]{{[/\\]+}}lib{{[/\\]+}}baremetal"
[clang][Driver] Handle risvc in Baremetal.cpp. 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
2020-11-26 19:31:45 +08:00
// CHECK-RV64-LIBSTDCXX-SAME: "-lstdc++" "-lsupc++" "-lunwind"
// CHECK-RV64-LIBSTDCXX-SAME: "-lc" "-lm" "-lclang_rt.builtins-riscv64"
// CHECK-RV64-LIBSTDCXX-SAME: "-o" "{{.*}}.o"
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: -target riscv32-unknown-elf \
// RUN: -L some/directory/user/asked/for \
// RUN: --sysroot=%S/Inputs/basic_riscv32_tree/riscv32-unknown-elf \
// RUN: | FileCheck --check-prefix=CHECK-RV32 %s
// CHECK-RV32: "[[PREFIX_DIR:.*]]{{[/\\]+}}{{[^/^\\]+}}{{[/\\]+}}clang{{.*}}" "-cc1" "-triple" "riscv32-unknown-unknown-elf"
// CHECK-RV32-SAME: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
// CHECK-RV32-SAME: "-isysroot" "[[SYSROOT:[^"]*]]"
// CHECK-RV32-SAME: "-internal-isystem" "[[SYSROOT]]{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}v1"
// CHECK-RV32-SAME: "-internal-isystem" "[[SYSROOT]]{{[/\\]+}}include"
// CHECK-RV32-SAME: "-x" "c++" "{{.*}}baremetal.cpp"
// CHECK-RV32-NEXT: "{{[^"]*}}ld{{(\.(lld|bfd|gold))?}}{{(\.exe)?}}" "{{.*}}.o" "-Bstatic"
// CHECK-RV32-SAME: "-Lsome{{[/\\]+}}directory{{[/\\]+}}user{{[/\\]+}}asked{{[/\\]+}}for"
[BareMetal] Ensure that sysroot always comes after library paths 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
2021-05-07 14:05:39 +08:00
// CHECK-RV32-SAME: "-L[[SYSROOT:[^"]+]]{{[/\\]+}}lib"
// CHECK-RV32-SAME: "-L[[RESOURCE_DIR:[^"]+]]{{[/\\]+}}lib{{[/\\]+}}baremetal"
[clang][Driver] Handle risvc in Baremetal.cpp. 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
2020-11-26 19:31:45 +08:00
// CHECK-RV32-SAME: "-lc" "-lm" "-lclang_rt.builtins-riscv32"
// CHECK-RV32-SAME: "-o" "{{.*}}.o"
// RUN: %clangxx -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: -target riscv32-unknown-elf \
// RUN: --sysroot=%S/Inputs/basic_riscv32_tree/riscv32-unknown-elf \
// RUN: | FileCheck --check-prefix=CHECK-RV32-DEFAULTCXX %s
[Driver] Fix architecture triplets and search paths for Linux x32 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
2021-04-01 16:47:56 +08:00
// CHECK-RV32-DEFAULTCXX: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
[clang][Driver] Handle risvc in Baremetal.cpp. 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
2020-11-26 19:31:45 +08:00
// CHECK-RV32-DEFAULTCXX: "{{[^"]*}}ld{{(\.(lld|bfd|gold))?}}{{(\.exe)?}}" "{{.*}}.o" "-Bstatic"
// CHECK-RV32-DEFAULTCXX-SAME: "-L{{[^"]*}}{{[/\\]+}}Inputs{{[/\\]+}}basic_riscv32_tree{{[/\\]+}}riscv32-unknown-elf{{[/\\]+}}lib"
[BareMetal] Ensure that sysroot always comes after library paths 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
2021-05-07 14:05:39 +08:00
// CHECK-RV32-DEFAULTCXX-SAME: "-L[[RESOURCE_DIR]]{{[/\\]+}}lib{{[/\\]+}}baremetal"
[clang][Driver] Handle risvc in Baremetal.cpp. 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
2020-11-26 19:31:45 +08:00
// CHECK-RV32-DEFAULTCXX-SAME: "-lc++" "-lc++abi" "-lunwind"
// CHECK-RV32-DEFAULTCXX-SAME: "-lc" "-lm" "-lclang_rt.builtins-riscv32"
// CHECK-RV32-DEFAULTCXX-SAME: "-o" "{{.*}}.o"
// RUN: %clangxx -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: -target riscv32-unknown-elf \
// RUN: --sysroot=%S/Inputs/basic_riscv32_tree/riscv32-unknown-elf \
// RUN: -stdlib=libc++ \
// RUN: | FileCheck --check-prefix=CHECK-RV32-LIBCXX %s
[Driver] Fix architecture triplets and search paths for Linux x32 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
2021-04-01 16:47:56 +08:00
// CHECK-RV32-LIBCXX: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
[clang][Driver] Handle risvc in Baremetal.cpp. 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
2020-11-26 19:31:45 +08:00
// CHECK-RV32-LIBCXX-NOT: "-internal-isystem" "{{[^"]+}}{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}{{[^v].*}}"
[Driver] Fix architecture triplets and search paths for Linux x32 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
2021-04-01 16:47:56 +08:00
// CHECK-RV32-LIBCXX-SAME: "-internal-isystem" "{{[^"]+}}{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}v1"
[clang][Driver] Handle risvc in Baremetal.cpp. 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
2020-11-26 19:31:45 +08:00
// CHECK-RV32-LIBCXX: "{{[^"]*}}ld{{(\.(lld|bfd|gold))?}}{{(\.exe)?}}" "{{.*}}.o" "-Bstatic"
// CHECK-RV32-LIBCXX-SAME: "-L{{[^"]*}}{{[/\\]+}}Inputs{{[/\\]+}}basic_riscv32_tree{{[/\\]+}}riscv32-unknown-elf{{[/\\]+}}lib"
[BareMetal] Ensure that sysroot always comes after library paths 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
2021-05-07 14:05:39 +08:00
// CHECK-RV32-LIBCXX-SAME: "-L[[RESOURCE_DIR]]{{[/\\]+}}lib{{[/\\]+}}baremetal"
[clang][Driver] Handle risvc in Baremetal.cpp. 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
2020-11-26 19:31:45 +08:00
// CHECK-RV32-LIBCXX-SAME: "-lc++" "-lc++abi" "-lunwind"
// CHECK-RV32-LIBCXX-SAME: "-lc" "-lm" "-lclang_rt.builtins-riscv32"
// CHECK-RV32-LIBCXX-SAME: "-o" "{{.*}}.o"
// RUN: %clangxx -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: -target riscv32-unknown-elf \
// RUN: --sysroot=%S/Inputs/basic_riscv32_tree/riscv32-unknown-elf \
// RUN: -stdlib=libstdc++ \
// RUN: | FileCheck --check-prefix=CHECK-RV32-LIBSTDCXX %s
[Driver] Fix architecture triplets and search paths for Linux x32 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
2021-04-01 16:47:56 +08:00
// CHECK-RV32-LIBSTDCXX: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
[clang][Driver] Handle risvc in Baremetal.cpp. 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
2020-11-26 19:31:45 +08:00
// CHECK-RV32-LIBSTDCXX-NOT: "-internal-isystem" "{{[^"]+}}{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}v1"
[Driver] Fix architecture triplets and search paths for Linux x32 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
2021-04-01 16:47:56 +08:00
// CHECK-RV32-LIBSTDCXX-SAME: "-internal-isystem" "{{[^"]+}}{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}8.0.1"
[clang][Driver] Handle risvc in Baremetal.cpp. 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
2020-11-26 19:31:45 +08:00
// CHECK-RV32-LIBSTDCXX: "{{[^"]*}}ld{{(\.(lld|bfd|gold))?}}{{(\.exe)?}}" "{{.*}}.o" "-Bstatic"
// CHECK-RV32-LIBSTDCXX-SAME: "-L{{[^"]*}}{{[/\\]+}}Inputs{{[/\\]+}}basic_riscv32_tree{{[/\\]+}}riscv32-unknown-elf{{[/\\]+}}lib"
[BareMetal] Ensure that sysroot always comes after library paths 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
2021-05-07 14:05:39 +08:00
// CHECK-RV32-LIBSTDCXX-SAME: "-L[[RESOURCE_DIR]]{{[/\\]+}}lib{{[/\\]+}}baremetal"
[clang][Driver] Handle risvc in Baremetal.cpp. 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
2020-11-26 19:31:45 +08:00
// CHECK-RV32-LIBSTDCXX-SAME: "-lstdc++" "-lsupc++" "-lunwind"
// CHECK-RV32-LIBSTDCXX-SAME: "-lc" "-lm" "-lclang_rt.builtins-riscv32"
// CHECK-RV32-LIBSTDCXX-SAME: "-o" "{{.*}}.o"
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: -target riscv64-unknown-elf \
// RUN: -nostdlibinc -nobuiltininc \
// RUN: --sysroot=%S/Inputs/basic_riscv64_tree/riscv64-unknown-elf \
// RUN: | FileCheck --check-prefix=CHECK-RV64-LIBINC %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: -target riscv64-unknown-elf \
// RUN: -nostdinc \
// RUN: --sysroot=%S/Inputs/basic_riscv64_tree/riscv64-unknown-elf \
// RUN: | FileCheck --check-prefix=CHECK-RV64-LIBINC %s
// CHECK-RV64-LIBINC-NOT: "-internal-isystem"
// RUN: %clangxx -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: -target riscv64-unknown-elf \
// RUN: --sysroot=%S/Inputs/basic_riscv64_tree/riscv64-unknown-elf \
// RUN: -nodefaultlibs \
// RUN: | FileCheck --check-prefix=CHECK-RV64-NDL %s
[Driver] Fix architecture triplets and search paths for Linux x32 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
2021-04-01 16:47:56 +08:00
// CHECK-RV64-NDL: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
[clang][Driver] Handle risvc in Baremetal.cpp. 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
2020-11-26 19:31:45 +08:00
// CHECK-RV64-NDL: "{{[^"]*}}ld{{(\.(lld|bfd|gold))?}}{{(\.exe)?}}" "{{.*}}.o" "-Bstatic"
// CHECK-RV64-NDL-SAME: "-L{{[^"]*}}{{[/\\]+}}Inputs{{[/\\]+}}basic_riscv64_tree{{[/\\]+}}riscv64-unknown-elf{{[/\\]+}}lib"
[BareMetal] Ensure that sysroot always comes after library paths 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
2021-05-07 14:05:39 +08:00
// CHECK-RV64-NDL-SAME: "-L[[RESOURCE_DIR]]{{[/\\]+}}lib{{[/\\]+}}baremetal"
[clang][Driver] Handle risvc in Baremetal.cpp. 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
2020-11-26 19:31:45 +08:00
// CHECK-RV64-NDL-SAME: "-o" "{{.*}}.o"
Add initial support for multilibs in Baremetal toolchain. 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
2020-12-15 03:11:51 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: -target riscv64-unknown-elf \
// RUN: -march=rv64imafdc -mabi=lp64d \
// RUN: --sysroot=%S/Inputs/basic_riscv64_tree/riscv64-unknown-elf \
// RUN: | FileCheck --check-prefix=CHECK-RV64FD %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: -target riscv64-unknown-elf \
// RUN: -march=rv64gc -mabi=lp64d \
// RUN: --sysroot=%S/Inputs/basic_riscv64_tree/riscv64-unknown-elf \
// RUN: | FileCheck --check-prefix=CHECK-RV64FD %s
// CHECK-RV64FD: "[[PREFIX_DIR:.*]]{{[/\\]+}}{{[^/^\\]+}}{{[/\\]+}}clang{{.*}}" "-cc1" "-triple" "riscv64-unknown-unknown-elf"
// CHECK-RV64FD-SAME: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
// CHECK-RV64FD-SAME: "-isysroot" "[[SYSROOT:[^"]*]]"
// CHECK-RV64FD-SAME: "-internal-isystem" "[[SYSROOT]]{{[/\\]+}}rv64imafdc{{[/\\]+}}lp64d{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}v1"
// CHECk-RV64FD-SAME: "-internal-isystem" "[[SYSROOT]]{{[/\\]+}}rv64imafdc{{[/\\]+}}lp64d{{[/\\]+}}include"
// CHECK-RV64FD-SAME: "-x" "c++" "{{.*}}baremetal.cpp"
// CHECK-RV64FD-NEXT: "{{[^"]*}}ld{{(\.(lld|bfd|gold))?}}{{(\.exe)?}}" "{{.*}}.o" "-Bstatic"
// CHECK-RV64FD-SAME: "-L[[SYSROOT:[^"]+]]{{[/\\]+}}rv64imafdc{{[/\\]+}}lp64d{{[/\\]+}}lib"
[BareMetal] Ensure that sysroot always comes after library paths 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
2021-05-07 14:05:39 +08:00
// CHECK-RV64FD-SAME: "-L[[RESOURCE_DIR:[^"]+]]{{[/\\]+}}lib{{[/\\]+}}baremetal{{[/\\]+}}rv64imafdc{{[/\\]+}}lp64d"
Add initial support for multilibs in Baremetal toolchain. 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
2020-12-15 03:11:51 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: -target riscv32-unknown-elf \
// RUN: -march=rv32i -mabi=ilp32 \
// RUN: --sysroot=%S/Inputs/basic_riscv32_tree/riscv32-unknown-elf \
// RUN: | FileCheck --check-prefix=CHECK-RV32I %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: -target riscv32-unknown-elf \
// RUN: -march=rv32ic -mabi=ilp32 \
// RUN: --sysroot=%S/Inputs/basic_riscv32_tree/riscv32-unknown-elf \
// RUN: | FileCheck --check-prefix=CHECK-RV32I %s
// CHECK-RV32I: "[[PREFIX_DIR:.*]]{{[/\\]+}}{{[^/^\\]+}}{{[/\\]+}}clang{{.*}}" "-cc1" "-triple" "riscv32-unknown-unknown-elf"
// CHECK-RV32I-SAME: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
// CHECK-RV32I-SAME: "-isysroot" "[[SYSROOT:[^"]*]]"
// CHECK-RV32I-SAME: "-internal-isystem" "[[SYSROOT]]{{[/\\]+}}rv32i{{[/\\]+}}ilp32{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}v1"
// CHECK-RV32I-SAME: "-internal-isystem" "[[SYSROOT]]{{[/\\]+}}rv32i{{[/\\]+}}ilp32{{[/\\]+}}include"
// CHECK-RV32I-SAME: "-x" "c++" "{{.*}}baremetal.cpp"
// CHECK-RV32I-NEXT: "{{[^"]*}}ld{{(\.(lld|bfd|gold))?}}{{(\.exe)?}}" "{{.*}}.o" "-Bstatic"
// CHECK-RV32I-SAME: "-L[[SYSROOT:[^"]+]]{{[/\\]+}}rv32i{{[/\\]+}}ilp32{{[/\\]+}}lib"
[BareMetal] Ensure that sysroot always comes after library paths 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
2021-05-07 14:05:39 +08:00
// CHECK-RV32I-SAME: "-L[[RESOURCE_DIR:[^"]+]]{{[/\\]+}}lib{{[/\\]+}}baremetal{{[/\\]+}}rv32i{{[/\\]+}}ilp32"
Add initial support for multilibs in Baremetal toolchain. 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
2020-12-15 03:11:51 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: -target riscv32-unknown-elf \
// RUN: -march=rv32im -mabi=ilp32 \
// RUN: --sysroot=%S/Inputs/basic_riscv32_tree/riscv32-unknown-elf \
// RUN: | FileCheck --check-prefix=CHECK-RV32IM %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: -target riscv32-unknown-elf \
// RUN: -march=rv32imc -mabi=ilp32 \
// RUN: --sysroot=%S/Inputs/basic_riscv32_tree/riscv32-unknown-elf \
// RUN: | FileCheck --check-prefix=CHECK-RV32IM %s
// CHECK-RV32IM: "[[PREFIX_DIR:.*]]{{[/\\]+}}{{[^/^\\]+}}{{[/\\]+}}clang{{.*}}" "-cc1" "-triple" "riscv32-unknown-unknown-elf"
// CHECK-RV32IM-SAME: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
// CHECK-RV32IM-SAME: "-isysroot" "[[SYSROOT:[^"]*]]"
// CHECK-RV32IM-SAME: "-internal-isystem" "[[SYSROOT]]{{[/\\]+}}rv32im{{[/\\]+}}ilp32{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}v1"
// CHECK-RV32IM-SAME: "-internal-isystem" "[[SYSROOT]]{{[/\\]+}}rv32im{{[/\\]+}}ilp32{{[/\\]+}}include"
// CHECK-RV32IM-SAME: "-x" "c++" "{{.*}}baremetal.cpp"
// CHECK-RV32IM-NEXT: "{{[^"]*}}ld{{(\.(lld|bfd|gold))?}}{{(\.exe)?}}" "{{.*}}.o" "-Bstatic"
// CHECK-RV32IM-SAME: "-L[[SYSROOT:[^"]+]]{{[/\\]+}}rv32im{{[/\\]+}}ilp32{{[/\\]+}}lib"
[BareMetal] Ensure that sysroot always comes after library paths 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
2021-05-07 14:05:39 +08:00
// CHECK-RV32IM-SAME: "-L[[RESOURCE_DIR:[^"]+]]{{[/\\]+}}lib{{[/\\]+}}baremetal{{[/\\]+}}rv32im{{[/\\]+}}ilp32"
Add initial support for multilibs in Baremetal toolchain. 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
2020-12-15 03:11:51 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: -target riscv32-unknown-elf \
// RUN: -march=rv32iac -mabi=ilp32 \
// RUN: --sysroot=%S/Inputs/basic_riscv32_tree/riscv32-unknown-elf \
// RUN: | FileCheck --check-prefix=CHECK-RV32IAC %s
// CHECK-RV32IAC: "[[PREFIX_DIR:.*]]{{[/\\]+}}{{[^/^\\]+}}{{[/\\]+}}clang{{.*}}" "-cc1" "-triple" "riscv32-unknown-unknown-elf"
// CHECK-RV32IAC-SAME: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
// CHECK-RV32IAC-SAME: "-isysroot" "[[SYSROOT:[^"]*]]"
// CHECK-RV32IAC-SAME: "-internal-isystem" "[[SYSROOT]]{{[/\\]+}}rv32iac{{[/\\]+}}ilp32{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}v1"
// CHECK-RV32IAC-SAME: "-internal-isystem" "[[SYSROOT]]{{[/\\]+}}rv32iac{{[/\\]+}}ilp32{{[/\\]+}}include"
// CHECK-RV32IAC-SAME: "-x" "c++" "{{.*}}baremetal.cpp"
// CHECK-RV32IAC-NEXT: "{{[^"]*}}ld{{(\.(lld|bfd|gold))?}}{{(\.exe)?}}" "{{.*}}.o" "-Bstatic"
// CHECK-RV32IAC-SAME: "-L[[SYSROOT:[^"]+]]{{[/\\]+}}rv32iac{{[/\\]+}}ilp32{{[/\\]+}}lib"
[BareMetal] Ensure that sysroot always comes after library paths 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
2021-05-07 14:05:39 +08:00
// CHECK-RV32IAC-SAME: "-L[[RESOURCE_DIR:[^"]+]]{{[/\\]+}}lib{{[/\\]+}}baremetal{{[/\\]+}}rv32iac{{[/\\]+}}ilp32"
Add initial support for multilibs in Baremetal toolchain. 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
2020-12-15 03:11:51 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: -target riscv32-unknown-elf \
// RUN: -march=rv32imafc -mabi=ilp32f \
// RUN: --sysroot=%S/Inputs/basic_riscv32_tree/riscv32-unknown-elf \
// RUN: | FileCheck --check-prefix=CHECK-RV32IMAFC %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: -target riscv32-unknown-elf \
// RUN: -march=rv32imafdc -mabi=ilp32f \
// RUN: --sysroot=%S/Inputs/basic_riscv32_tree/riscv32-unknown-elf \
// RUN: | FileCheck --check-prefix=CHECK-RV32IMAFC %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: -target riscv32-unknown-elf \
// RUN: -march=rv32gc -mabi=ilp32f \
// RUN: --sysroot=%S/Inputs/basic_riscv32_tree/riscv32-unknown-elf \
// RUN: | FileCheck --check-prefix=CHECK-RV32IMAFC %s
// CHECK-RV32IMAFC: "[[PREFIX_DIR:.*]]{{[/\\]+}}{{[^/^\\]+}}{{[/\\]+}}clang{{.*}}" "-cc1" "-triple" "riscv32-unknown-unknown-elf"
// CHECK-RV32IMAFC-SAME: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
// CHECK-RV32IMAFC-SAME: "-isysroot" "[[SYSROOT:[^"]*]]"
// CHECK-RV32IMAFC-SAME: "-internal-isystem" "[[SYSROOT]]{{[/\\]+}}rv32imafc{{[/\\]+}}ilp32f{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}v1"
// CHECK-RV32IMAFC-SAME: "-internal-isystem" "[[SYSROOT]]{{[/\\]+}}rv32imafc{{[/\\]+}}ilp32f{{[/\\]+}}include"
// CHECK-RV32IMAFC-SAME: "-x" "c++" "{{.*}}baremetal.cpp"
// CHECK-RV32IMAFC-NEXT: "{{[^"]*}}ld{{(\.(lld|bfd|gold))?}}{{(\.exe)?}}" "{{.*}}.o" "-Bstatic"
// CHECK-RV32IMAFC-SAME: "-L[[SYSROOT:[^"]+]]{{[/\\]+}}rv32imafc{{[/\\]+}}ilp32f{{[/\\]+}}lib"
[BareMetal] Ensure that sysroot always comes after library paths 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
2021-05-07 14:05:39 +08:00
// CHECK-RV32IMAFC-SAME: "-L[[RESOURCE_DIR:[^"]+]]{{[/\\]+}}lib{{[/\\]+}}baremetal{{[/\\]+}}rv32imafc{{[/\\]+}}ilp32f"