[Buildroot] [PATCH v2 00/12] Add the support for Clang cross-compiler

[Buildroot] [PATCH v2 00/12] Add the support for Clang cross-compiler

[Romain Naour]

Last year Valentin Korenblit added during his internship at Smile,
llvm/clang packages to provide llvm/clang libraries for the target.
See the article from Valentin on Linuxembedded blog [1].

But Clang could not be used as a cross-compiler by Buildroot since
it was necessary to build the Linux kernel with GCC [2].

Recently, I've tried to build an aarch64 Linux kernel (5.2.7) with
Clang and it worked under Qemu [3]. I also tested for x86_64 but we need
the upcomming llvm/clang version 9 to build the kernel [4].
This new version add the support of "asm-goto" which was the last
missing part to be able to build the Linux kernel on x86_64 [5].
But for theses tests, only the kernel was built with Clang.

While testing the x86_64 kernel and it's rootfs built with Clang under Qemu,
I had a runtime issue during the userspace boot process (Busybox's init).
While searching about the issue, I discover the lowRISC blog from Lu??s Marques
about the same issue and tested the patch he contributed to the Busybox project
(Thanks!).

So, this series is about to complete the integration of Clang as cross-compiler
by using a toolchain-wrapper and fixing some build system infrastructure
(cmake, meson) to use Clang instead of GCC.

Add this new experimental option into "Advanced" menu since we are expecting
some build and runtime issues for number of packages (bootloaders, kernel).

For now, Clang cross-compiler can only be use as internal toolchain,
so it is build from the source which take a long time...

[1] http://www.linuxembedded.fr/2018/07/llvmclang-integration-into-buildroot
[2] https://www.elinux.org/Buildroot:DeveloperDaysFOSDEM2018#LLVM.2FClang
[3] http://www.linuxembedded.fr/2019/08/my-first-linux-kernel-built-with-clang-compiler
[4] https://www.phoronix.com/scan.php?page=news_item&px=LLVM-9.0-RC3-Released
[5] https://www.phoronix.com/scan.php?page=news_item&px=LLVM-Asm-Goto-Merged
[6] https://www.lowrisc.org/blog/2019/07/large-scale-risc-v-llvm-testing-with-buildroot

Best regards,
Romain

v2: Fix pkg-meson (missing $) and keep TARGET_CROSS in sed command for other tools (as etc).
    Install the GCC external toolchain before executing realpath command.
	Move host-clang dependency to toolchain virtual package since host-clang now
	 depends on external-toolchain.
	Add Glibc toolchain dependency
	Use GCC to build Glibc for internal toolchain.

Romain Naour (12):
  package/clang: help host-clang to find our external toolchain
  package/llvm: add the version major variable
  package/clang: add the version major variable
  package/clang: install a toolchain-wrapper for the host clang
    cross-compiler
  linux: override CC for the case CC is not GCC
  package/meson: use TARGET_{CC,CXX} instead of TARGET_CROSS for cc and
    cpp
  package/busybox: fix applets runtime issue when building with clang
    cross-compiler
  package/clang: add a host entry for clang
  package/glibc: use GCC cross-compiler if Clang is used as
    cross-compiler
  core: allow to use Clang as cross-compiler
  toolchain: add a warning when Clang is used as cross-compiler
  linux: don't set -Wno-attribute-alias flag when Clang is used as
    cross-compiler

 Config.in                                     |  23 +++
 linux/linux.mk                                |   4 +-
 package/Config.in.host                        |   1 +
 package/Makefile.in                           |  13 +-
 ...use-BB_GLOBAL_CONST-where-applicable.patch | 173 ++++++++++++++++++
 ...hains-Gnu-Use-GCC_INSTALL_PREFIX-in-.patch |  76 ++++++++
 package/clang/Config.in.host                  |  19 ++
 package/clang/clang.mk                        |  51 +++++-
 package/glibc/glibc.mk                        |   5 +
 package/llvm/llvm.mk                          |   3 +-
 package/meson/cross-compilation.conf.in       |   4 +-
 package/meson/meson.mk                        |   2 +
 package/pkg-meson.mk                          |   2 +
 toolchain/Config.in                           |   6 +
 toolchain/toolchain/toolchain.mk              |   7 +
 15 files changed, 381 insertions(+), 8 deletions(-)
 create mode 100644 package/busybox/0003-use-BB_GLOBAL_CONST-where-applicable.patch
 create mode 100644 package/clang/0001-lib-Driver-ToolChains-Gnu-Use-GCC_INSTALL_PREFIX-in-.patch
 create mode 100644 package/clang/Config.in.host

-- 
2.21.0

[Buildroot] [PATCH v2 01/12] package/clang: help host-clang to find our external toolchain

[Romain Naour]

To build libfuzzer package Matthew Weber noticed that (host) clang
doesn't run on the host without "-B $(HOST_DIR)/opt/ext-toolchain"
option. This option add a new search path for binaries and object
files used implicitly.

Without -B clang fail to link due to missing crtbeging.o file and libgcc:
output/host/bin/aarch64-linux-gnu-ld: cannot find crtbegin.o: No such file or directory
output/host/bin/aarch64-linux-gnu-ld: cannot find -lgcc

Indeed, clang search path doesn't include the dafault cross-gcc's search paths:

$ output/host/bin/clang -print-search-dirs
programs: = output/host/bin:output/host/bin:/..//bin
libraries: = output/host/lib/clang/8.0.0:
             output/host/bin/../lib64:
             /lib/../lib64:
             /usr/lib/../lib64:
             output/host/bin/../lib:
             /lib:/usr/lib

Here is the same command for cross-gcc:

$ output/host/bin/aarch64-linux-gnu-gcc -print-search-dirs
install: output/host/opt/ext-toolchain/bin/../lib/gcc/aarch64-linux-gnu/8.3.0/
programs: = output/host/opt/ext-toolchain/bin/../libexec/gcc/aarch64-linux-gnu/8.3.0/:
            output/host/opt/ext-toolchain/bin/../libexec/gcc/:
            output/host/opt/ext-toolchain/bin/../lib/gcc/aarch64-linux-gnu/8.3.0/../../../../aarch64-linux-gnu/bin/aarch64-linux-gnu/8.3.0/:
            output/host/opt/ext-toolchain/bin/../lib/gcc/aarch64-linux-gnu/8.3.0/../../../../aarch64-linux-gnu/bin/
libraries: = output/opt/ext-toolchain/bin/../lib/gcc/aarch64-linux-gnu/8.3.0/:
             output/host/opt/ext-toolchain/bin/../lib/gcc/:
             output/host/opt/ext-toolchain/bin/../lib/gcc/aarch64-linux-gnu/8.3.0/../../../../aarch64-linux-gnu/lib/aarch64-linux-gnu/8.3.0/:
             output/host/opt/ext-toolchain/bin/../lib/gcc/aarch64-linux-gnu/8.3.0/../../../../aarch64-linux-gnu/lib/../lib64/:
             output/host/aarch64-buildroot-linux-gnu/sysroot/lib/aarch64-linux-gnu/8.3.0/:
             output/host/aarch64-buildroot-linux-gnu/sysroot/lib/../lib64/:
             output/host/aarch64-buildroot-linux-gnu/sysroot/usr/lib/aarch64-linux-gnu/8.3.0/:
             output/host/aarch64-buildroot-linux-gnu/sysroot/usr/lib/../lib64/:
             output/host/opt/ext-toolchain/bin/../lib/gcc/aarch64-linux-gnu/8.3.0/../../../../aarch64-linux-gnu/lib/:
             output/host/aarch64-buildroot-linux-gnu/sysroot/lib/:
             output/host/aarch64-buildroot-linux-gnu/sysroot/usr/lib/

We can see that gcc default search path contains
"output/host/opt/ext-toolchain" directory where the external toolchain
has been extracted.

Since we want to use clang without additional option like -B,
patch clang in order to use GCC_INSTALL_PREFIX instead of
using automatic detection (which doesn't work for Buildroot).

We eventually want to relocate the Buildroot SDK containing the clang
cross-compiler, so we provide a relative path to GCC_INSTALL_PREFIX
in order to avoid to hardcode the path to the GCC toolchain.

Also the path between clang and the GCC external toolchain is not always
the same, we have the following case:

* Toolchain to be downloaded and installed
  The toolchain is extracted into $(HOST_DIR)/opt/ext-toolchain, so the
  path is "../opt/ext-toolchain".

* Pre-installed toolchain
  The toolchain is localed somewhere in the host filesystem and
  defined by the user using BR2_TOOLCHAIN_EXTERNAL_PATH.

So, set GCC_INSTALL_PREFIX using realpath:

-DGCC_INSTALL_PREFIX:PATH=`realpath --relative-to=$(HOST_DIR)/bin/ $(TOOLCHAIN_EXTERNAL_INSTALL_DIR)`

When we use a Buildroot's internal toolchain, clang will find theses
crt*.o files and libgcc.

http://lists.busybox.net/pipermail/buildroot/2019-August/256204.html

Signed-off-by: Romain Naour <romain.naour@smile.fr>
Cc: Matthew Weber <matthew.weber@rockwellcollins.com>
Cc: Valentin Korenblit <valentinkorenblit@gmail.com>
---
v2: don't hack the external toolchain infra.
    patch clang and provide GCC_INSTALL_PREFIX
---
 ...hains-Gnu-Use-GCC_INSTALL_PREFIX-in-.patch | 76 +++++++++++++++++++
 package/clang/clang.mk                        |  7 ++
 2 files changed, 83 insertions(+)
 create mode 100644 package/clang/0001-lib-Driver-ToolChains-Gnu-Use-GCC_INSTALL_PREFIX-in-.patch

diff --git a/package/clang/0001-lib-Driver-ToolChains-Gnu-Use-GCC_INSTALL_PREFIX-in-.patch b/package/clang/0001-lib-Driver-ToolChains-Gnu-Use-GCC_INSTALL_PREFIX-in-.patch
new file mode 100644
index 0000000000..63ddbaf35f
--- /dev/null
+++ b/package/clang/0001-lib-Driver-ToolChains-Gnu-Use-GCC_INSTALL_PREFIX-in-.patch
@@ -0,0 +1,76 @@
+From fe21cede3939a435d62efbd5799547fab6af1b0a Mon Sep 17 00:00:00 2001
+From: Romain Naour <romain.naour@smile.fr>
+Date: Mon, 5 Aug 2019 16:06:48 +0200
+Subject: [PATCH] lib/Driver/ToolChains/Gnu: Use GCC_INSTALL_PREFIX in the set
+ of prefixes for searching the gcc toolchain
+
+By default, the Gnu Toolchains driver is looking at the parent
+directory while looking for the gcc toolchain when clang is installed
+at "D.InstalledDir"
+
+But this doesn't work with Buildroot since the external
+toolchain is installed in host/opt/ext-toolchain and the sysroot is
+moved to host/<arch>-buildroot-linux-gnu/sysroot/ directory.
+
+We tried by setting GCC_INSTALL_PREFIX in clang.mk for host-clang
+but it doesn't work since we already provide a sysroot [1].
+
+Help the Gnu Toolchains driver by using GCC_INSTALL_PREFIX path.
+
+Since we want to be able to relocate the clang toolchain,
+allow to use a relative path with GCC_INSTALL_PREFIX.
+
+Buildroot will provide such relative path by using:
+HOST_CLANG_CONF_OPTS += -DGCC_INSTALL_PREFIX:PATH=`realpath --relative-to=$(HOST_DIR)/bin/ $(TOOLCHAIN_EXTERNAL_INSTALL_DIR)`
+
+Doing so allow to use clang without providing additional search
+paths with -B option on the clang's command line.
+
+[1] https://reviews.llvm.org/D49244
+[2] http://lists.busybox.net/pipermail/buildroot/2019-August/256204.html
+
+Signed-off-by: Romain Naour <romain.naour@smile.fr>
+---
+This issue needs to be reported and discussed with upstream.
+---
+ lib/Driver/ToolChains/Gnu.cpp | 17 +++++++++++++++++
+ 1 file changed, 17 insertions(+)
+
+diff --git a/lib/Driver/ToolChains/Gnu.cpp b/lib/Driver/ToolChains/Gnu.cpp
+index 2ad45097dc..90d6b5b748 100644
+--- a/lib/Driver/ToolChains/Gnu.cpp
++++ b/lib/Driver/ToolChains/Gnu.cpp
+@@ -1725,6 +1725,8 @@ void Generic_GCC::GCCInstallationDetector::init(
+ 
+     Prefixes.push_back(GCCToolchainDir);
+   } else {
++    StringRef GccIinstallPrefix = GCC_INSTALL_PREFIX;
++
+     // If we have a SysRoot, try that first.
+     if (!D.SysRoot.empty()) {
+       Prefixes.push_back(D.SysRoot);
+@@ -1734,6 +1736,21 @@ void Generic_GCC::GCCInstallationDetector::init(
+     // Then look for gcc installed alongside clang.
+     Prefixes.push_back(D.InstalledDir + "/..");
+ 
++    // Use GCC_INSTALL_PREFIX if provided by the buildsystem.
++    if (!GccIinstallPrefix.empty())
++    {
++        if (llvm::sys::path::is_relative(GccIinstallPrefix))
++        {
++            // Use a relative path to gcc from clang install path.
++            Prefixes.push_back(D.InstalledDir + "/" + GccIinstallPrefix.str());
++        }
++        else
++        {
++            // Hardcode the absolute path provided by GCC_INSTALL_PREFIX.
++            Prefixes.push_back(GCC_INSTALL_PREFIX);
++        }
++    }
++
+     // Next, look for prefix(es) that correspond to distribution-supplied gcc
+     // installations.
+     if (D.SysRoot.empty()) {
+-- 
+2.20.1
+
diff --git a/package/clang/clang.mk b/package/clang/clang.mk
index 3796ca8605..ed6f9bf90e 100644
--- a/package/clang/clang.mk
+++ b/package/clang/clang.mk
@@ -102,5 +102,12 @@ CLANG_CONF_OPTS += -DLLVM_LINK_LLVM_DYLIB=ON
 HOST_CLANG_CONF_OPTS += -DLLVM_DYLIB_COMPONENTS=all
 CLANG_CONF_OPTS += -DLLVM_DYLIB_COMPONENTS=all
 
+# Help host-clang to find our external toolchain, use a relative path from the clang
+# installation directory to the external toolchain installation directory in order to
+# not hardcode the toolchain absolute path.
+ifeq ($(BR2_TOOLCHAIN_EXTERNAL),y)
+HOST_CLANG_CONF_OPTS += -DGCC_INSTALL_PREFIX:PATH=`realpath --relative-to=$(HOST_DIR)/bin/ $(TOOLCHAIN_EXTERNAL_INSTALL_DIR)`
+endif
+
 $(eval $(cmake-package))
 $(eval $(host-cmake-package))
-- 
2.21.0

[Buildroot] [PATCH v2 01/12] package/clang: help host-clang to find our external toolchain

[Matthew Weber]

Romain,

On Sat, Sep 7, 2019 at 4:40 AM Romain Naour <romain.naour@smile.fr> wrote:
>
> To build libfuzzer package Matthew Weber noticed that (host) clang
> doesn't run on the host without "-B $(HOST_DIR)/opt/ext-toolchain"
> option. This option add a new search path for binaries and object
> files used implicitly.
>
> Without -B clang fail to link due to missing crtbeging.o file and libgcc:
> output/host/bin/aarch64-linux-gnu-ld: cannot find crtbegin.o: No such file or directory
> output/host/bin/aarch64-linux-gnu-ld: cannot find -lgcc
>
> Indeed, clang search path doesn't include the dafault cross-gcc's search paths:
>
> $ output/host/bin/clang -print-search-dirs
> programs: = output/host/bin:output/host/bin:/..//bin
> libraries: = output/host/lib/clang/8.0.0:
>              output/host/bin/../lib64:
>              /lib/../lib64:
>              /usr/lib/../lib64:
>              output/host/bin/../lib:
>              /lib:/usr/lib
>
> Here is the same command for cross-gcc:
>
> $ output/host/bin/aarch64-linux-gnu-gcc -print-search-dirs
> install: output/host/opt/ext-toolchain/bin/../lib/gcc/aarch64-linux-gnu/8.3.0/
> programs: = output/host/opt/ext-toolchain/bin/../libexec/gcc/aarch64-linux-gnu/8.3.0/:
>             output/host/opt/ext-toolchain/bin/../libexec/gcc/:
>             output/host/opt/ext-toolchain/bin/../lib/gcc/aarch64-linux-gnu/8.3.0/../../../../aarch64-linux-gnu/bin/aarch64-linux-gnu/8.3.0/:
>             output/host/opt/ext-toolchain/bin/../lib/gcc/aarch64-linux-gnu/8.3.0/../../../../aarch64-linux-gnu/bin/
> libraries: = output/opt/ext-toolchain/bin/../lib/gcc/aarch64-linux-gnu/8.3.0/:
>              output/host/opt/ext-toolchain/bin/../lib/gcc/:
>              output/host/opt/ext-toolchain/bin/../lib/gcc/aarch64-linux-gnu/8.3.0/../../../../aarch64-linux-gnu/lib/aarch64-linux-gnu/8.3.0/:
>              output/host/opt/ext-toolchain/bin/../lib/gcc/aarch64-linux-gnu/8.3.0/../../../../aarch64-linux-gnu/lib/../lib64/:
>              output/host/aarch64-buildroot-linux-gnu/sysroot/lib/aarch64-linux-gnu/8.3.0/:
>              output/host/aarch64-buildroot-linux-gnu/sysroot/lib/../lib64/:
>              output/host/aarch64-buildroot-linux-gnu/sysroot/usr/lib/aarch64-linux-gnu/8.3.0/:
>              output/host/aarch64-buildroot-linux-gnu/sysroot/usr/lib/../lib64/:
>              output/host/opt/ext-toolchain/bin/../lib/gcc/aarch64-linux-gnu/8.3.0/../../../../aarch64-linux-gnu/lib/:
>              output/host/aarch64-buildroot-linux-gnu/sysroot/lib/:
>              output/host/aarch64-buildroot-linux-gnu/sysroot/usr/lib/
>
> We can see that gcc default search path contains
> "output/host/opt/ext-toolchain" directory where the external toolchain
> has been extracted.
>
> Since we want to use clang without additional option like -B,
> patch clang in order to use GCC_INSTALL_PREFIX instead of
> using automatic detection (which doesn't work for Buildroot).
>
> We eventually want to relocate the Buildroot SDK containing the clang
> cross-compiler, so we provide a relative path to GCC_INSTALL_PREFIX
> in order to avoid to hardcode the path to the GCC toolchain.
>
> Also the path between clang and the GCC external toolchain is not always
> the same, we have the following case:
>
> * Toolchain to be downloaded and installed
>   The toolchain is extracted into $(HOST_DIR)/opt/ext-toolchain, so the
>   path is "../opt/ext-toolchain".
>
> * Pre-installed toolchain
>   The toolchain is localed somewhere in the host filesystem and
>   defined by the user using BR2_TOOLCHAIN_EXTERNAL_PATH.
>
> So, set GCC_INSTALL_PREFIX using realpath:
>
> -DGCC_INSTALL_PREFIX:PATH=`realpath --relative-to=$(HOST_DIR)/bin/ $(TOOLCHAIN_EXTERNAL_INSTALL_DIR)`
>
> When we use a Buildroot's internal toolchain, clang will find theses
> crt*.o files and libgcc.
>
> http://lists.busybox.net/pipermail/buildroot/2019-August/256204.html
>
> Signed-off-by: Romain Naour <romain.naour@smile.fr>
> Cc: Matthew Weber <matthew.weber@rockwellcollins.com>
> Cc: Valentin Korenblit <valentinkorenblit@gmail.com>

My test consisted of applying this cross compiler series to master and
then applying the compilier-rt series.  In the compiler-rt series, the
-B option was dropped from the build of libfuzzer and the runtime test
was successful in building (ie it found the sysroot based on this
patch's path fix).

Tested-by: Matt Weber <matthew.weber@rockwellcollins.com>

[Buildroot] [PATCH v2 01/12] package/clang: help host-clang to find our external toolchain

[Arnout Vandecappelle]

On 07/09/2019 11:40, Romain Naour wrote:
[snip]
> diff --git a/package/clang/0001-lib-Driver-ToolChains-Gnu-Use-GCC_INSTALL_PREFIX-in-.patch b/package/clang/0001-lib-Driver-ToolChains-Gnu-Use-GCC_INSTALL_PREFIX-in-.patch
> new file mode 100644
> index 0000000000..63ddbaf35f
> --- /dev/null
> +++ b/package/clang/0001-lib-Driver-ToolChains-Gnu-Use-GCC_INSTALL_PREFIX-in-.patch
> @@ -0,0 +1,76 @@
> +From fe21cede3939a435d62efbd5799547fab6af1b0a Mon Sep 17 00:00:00 2001
> +From: Romain Naour <romain.naour@smile.fr>
> +Date: Mon, 5 Aug 2019 16:06:48 +0200
> +Subject: [PATCH] lib/Driver/ToolChains/Gnu: Use GCC_INSTALL_PREFIX in the set
> + of prefixes for searching the gcc toolchain
> +
> +By default, the Gnu Toolchains driver is looking at the parent
> +directory while looking for the gcc toolchain when clang is installed
> +at "D.InstalledDir"
> +
> +But this doesn't work with Buildroot since the external
> +toolchain is installed in host/opt/ext-toolchain and the sysroot is
> +moved to host/<arch>-buildroot-linux-gnu/sysroot/ directory.
> +
> +We tried by setting GCC_INSTALL_PREFIX in clang.mk for host-clang
> +but it doesn't work since we already provide a sysroot [1].
> +
> +Help the Gnu Toolchains driver by using GCC_INSTALL_PREFIX path.
> +
> +Since we want to be able to relocate the clang toolchain,
> +allow to use a relative path with GCC_INSTALL_PREFIX.

 Well, that's only true for a downloaded toolchain. A preinstalled toolchain is
assumed not to relocate when you relocate the SDK, so it should be an absolute
path. (Actually, we probably should use a relative path if the path given in the
.config is relative, but an absolute path if it is absolute...)

> +
> +Buildroot will provide such relative path by using:
> +HOST_CLANG_CONF_OPTS += -DGCC_INSTALL_PREFIX:PATH=`realpath --relative-to=$(HOST_DIR)/bin/ $(TOOLCHAIN_EXTERNAL_INSTALL_DIR)`
> +
> +Doing so allow to use clang without providing additional search
> +paths with -B option on the clang's command line.
> +
> +[1] https://reviews.llvm.org/D49244
> +[2] http://lists.busybox.net/pipermail/buildroot/2019-August/256204.html
> +
> +Signed-off-by: Romain Naour <romain.naour@smile.fr>
> +---
> +This issue needs to be reported and discussed with upstream.

 Did you do that in the end?

[snip]
> +# Help host-clang to find our external toolchain, use a relative path from the clang
> +# installation directory to the external toolchain installation directory in order to
> +# not hardcode the toolchain absolute path.
> +ifeq ($(BR2_TOOLCHAIN_EXTERNAL),y)
> +HOST_CLANG_CONF_OPTS += -DGCC_INSTALL_PREFIX:PATH=`realpath --relative-to=$(HOST_DIR)/bin/ $(TOOLCHAIN_EXTERNAL_INSTALL_DIR)`

 ... so I changed this to use a relative path only for the downloaded toolchain,
which removes the need for realpath because we can just set ../opt/ext-toolchain

 Also, the :PATH part isn't needed - it's typically added for variables that
aren't defined in the CMakeLists.txt to make sure that they have the correct
type, but this option is defined so setting type is not needed.


 Regards,
 Arnout

> +endif
> +
>  $(eval $(cmake-package))
>  $(eval $(host-cmake-package))
> 

[Buildroot] [PATCH v2 02/12] package/llvm: add the version major variable

[Romain Naour]

Signed-off-by: Romain Naour <romain.naour@smile.fr>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Valentin Korenblit <valentinkorenblit@gmail.com>
---
 package/llvm/llvm.mk | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/package/llvm/llvm.mk b/package/llvm/llvm.mk
index f14b537d94..e885c63f98 100644
--- a/package/llvm/llvm.mk
+++ b/package/llvm/llvm.mk
@@ -5,7 +5,8 @@
 ################################################################################
 
 # LLVM and Clang should be version bumped together
-LLVM_VERSION = 8.0.1
+LLVM_VERSION_MAJOR = 8
+LLVM_VERSION = $(LLVM_VERSION_MAJOR).0.1
 LLVM_SITE = https://github.com/llvm/llvm-project/releases/download/llvmorg-$(LLVM_VERSION)
 LLVM_SOURCE = llvm-$(LLVM_VERSION).src.tar.xz
 LLVM_LICENSE = NCSA
-- 
2.21.0

[Buildroot] [PATCH v2 02/12] package/llvm: add the version major variable

[Arnout Vandecappelle]

On 07/09/2019 11:40, Romain Naour wrote:
> Signed-off-by: Romain Naour <romain.naour@smile.fr>
> Cc: Matt Weber <matthew.weber@rockwellcollins.com>
> Cc: Valentin Korenblit <valentinkorenblit@gmail.com>
> ---
>  package/llvm/llvm.mk | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/package/llvm/llvm.mk b/package/llvm/llvm.mk
> index f14b537d94..e885c63f98 100644
> --- a/package/llvm/llvm.mk
> +++ b/package/llvm/llvm.mk
> @@ -5,7 +5,8 @@
>  ################################################################################
>  
>  # LLVM and Clang should be version bumped together
> -LLVM_VERSION = 8.0.1
> +LLVM_VERSION_MAJOR = 8

 I guess this is a leftover from previous iterations, because LLVM_VERSION_MAJOR
is not used anywhere in this series. So this patch can be dropped IMO.

 Regards,
 Arnout

> +LLVM_VERSION = $(LLVM_VERSION_MAJOR).0.1
>  LLVM_SITE = https://github.com/llvm/llvm-project/releases/download/llvmorg-$(LLVM_VERSION)
>  LLVM_SOURCE = llvm-$(LLVM_VERSION).src.tar.xz
>  LLVM_LICENSE = NCSA
> 

[Buildroot] [PATCH v2 03/12] package/clang: add the version major variable

[Romain Naour]

CLANG_VERSION_MAJOR will be used in a followup patch
to install the toolchain-wrapper for clang cross-compiler
and it's symlinks.

Signed-off-by: Romain Naour <romain.naour@smile.fr>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Valentin Korenblit <valentinkorenblit@gmail.com>
---
 package/clang/clang.mk | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/package/clang/clang.mk b/package/clang/clang.mk
index ed6f9bf90e..857ec148ac 100644
--- a/package/clang/clang.mk
+++ b/package/clang/clang.mk
@@ -5,7 +5,8 @@
 ################################################################################
 
 # LLVM and Clang should be version bumped together
-CLANG_VERSION = 8.0.1
+CLANG_VERSION_MAJOR = 8
+CLANG_VERSION = $(CLANG_VERSION_MAJOR).0.1
 CLANG_SITE = https://github.com/llvm/llvm-project/releases/download/llvmorg-$(CLANG_VERSION)
 CLANG_SOURCE = cfe-$(CLANG_VERSION).src.tar.xz
 CLANG_LICENSE = NCSA
-- 
2.21.0

[Buildroot] [PATCH v2 04/12] package/clang: install a toolchain-wrapper for the host clang cross-compiler

[Romain Naour]

In order to use clang as a host cross-compiler for Buildroot, we need
to provide at least the path to the sysroot (using --sysroot) and
some other compiler flags.

Hoppefully, we can reuse the toolchain wrapper for gcc since
clang support most of the gcc flags used in the Buildroot's toolchain
wrapper.

Only the flag -mfused-madd (deprecated since gcc 4.6) for mips is
not supported by clang. Since Clang require gcc >= 5.x this flag
can never be used.

Since host-clang is always build by Buildroot as an internal toolchain,
we have to use a second toolchain-wrapper called toolchain-wrapper-clang
when an external toolchain is used.
Inded, the two wrapper use a different path BR_CROSS_PATH_SUFFIX in this
case.

After building the clang toolchain wrapper, create the symlinks needed
to force package infrastructure to use clang througt the wrapper.

Initially clang install the clang-8 binary and create all other symlinks:

 # clang -> clang-8
 # clang++ -> clang
 # clang-8
 # clang-cl -> clang
 # clang-cpp -> clang

Use a post install hook to rename the clang-8 binary to clang-8.br_real
and recreate all symlinks:

 # clang -> toolchain-wrapper-clang
 # clang++ -> toolchain-wrapper-clang
 # clang-8 -> toolchain-wrapper-clang
 # clang-8.br_real
 # clang++.br_real -> clang-8.br_real
 # clang.br_real -> clang-8.br_real
 # clang-cl -> toolchain-wrapper-clang
 # clang-cl.br_real -> clang-8.br_real
 # clang-cpp -> toolchain-wrapper-clang
 # clang-cpp.br_real -> clang-8.br_real

Use the previously introduced CLANG_VERSION_MAJOR variable to create
theses symlinks.

Set BR_CROSS_PATH_SUFFIX to ".br_real" as for the Buildroot's internal
GCC toolchain backend to find the "real" clang binary installed in
$(HOST_DIR)/bin.

Borrow TOOLCHAIN_WRAPPER_BUILD and TOOLCHAIN_WRAPPER_INSTALL to
build and install the specific clang toolchain wrapper.

Signed-off-by: Romain Naour <romain.naour@smile.fr>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Valentin Korenblit <valentinkorenblit@gmail.com>
---
 package/clang/clang.mk | 34 ++++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/package/clang/clang.mk b/package/clang/clang.mk
index 857ec148ac..148df8e611 100644
--- a/package/clang/clang.mk
+++ b/package/clang/clang.mk
@@ -110,5 +110,39 @@ ifeq ($(BR2_TOOLCHAIN_EXTERNAL),y)
 HOST_CLANG_CONF_OPTS += -DGCC_INSTALL_PREFIX:PATH=`realpath --relative-to=$(HOST_DIR)/bin/ $(TOOLCHAIN_EXTERNAL_INSTALL_DIR)`
 endif
 
+define HOST_CLANG_INSTALL_WRAPPER_AND_SIMPLE_SYMLINKS
+	$(Q)cd $(HOST_DIR)/bin; \
+	for i in clang clang-$(CLANG_VERSION_MAJOR) clang++ clang-cl clang-cpp; do \
+		case "$$i" in \
+		*clang-$(CLANG_VERSION_MAJOR)) \
+			rm -f $$i.br_real; \
+			mv $$i $$i.br_real; \
+			ln -sf toolchain-wrapper-clang $$i; \
+			;; \
+		*) \
+			ln -snf toolchain-wrapper-clang $$i; \
+			ln -snf clang-$(CLANG_VERSION_MAJOR).br_real $$i.br_real; \
+			;; \
+		esac; \
+	done
+endef
+
+define HOST_CLANG_TOOLCHAIN_WRAPPER_BUILD
+	$(HOSTCC) $(HOST_CFLAGS) $(TOOLCHAIN_WRAPPER_ARGS) \
+		-s -Wl,--hash-style=$(TOOLCHAIN_WRAPPER_HASH_STYLE) \
+		toolchain/toolchain-wrapper.c \
+		-o $(@D)/toolchain-wrapper-clang
+endef
+
+define HOST_CLANG_TOOLCHAIN_WRAPPER_INSTALL
+	$(INSTALL) -D -m 0755 $(@D)/toolchain-wrapper-clang \
+		$(HOST_DIR)/bin/toolchain-wrapper-clang
+endef
+
+HOST_CLANG_TOOLCHAIN_WRAPPER_ARGS += -DBR_CROSS_PATH_SUFFIX='".br_real"'
+HOST_CLANG_POST_BUILD_HOOKS += HOST_CLANG_TOOLCHAIN_WRAPPER_BUILD
+HOST_CLANG_POST_INSTALL_HOOKS += HOST_CLANG_TOOLCHAIN_WRAPPER_INSTALL
+HOST_CLANG_POST_INSTALL_HOOKS += HOST_CLANG_INSTALL_WRAPPER_AND_SIMPLE_SYMLINKS
+
 $(eval $(cmake-package))
 $(eval $(host-cmake-package))
-- 
2.21.0

[Buildroot] [PATCH v2 04/12] package/clang: install a toolchain-wrapper for the host clang cross-compiler

[Arnout Vandecappelle]

On 07/09/2019 11:40, Romain Naour wrote:
> Since host-clang is always build by Buildroot as an internal toolchain,
> we have to use a second toolchain-wrapper called toolchain-wrapper-clang
> when an external toolchain is used.
> Inded, the two wrapper use a different path BR_CROSS_PATH_SUFFIX in this
> case.

 I didn't think this was very clear, so I reworded it as follows:

    host-clang refers to an existing GCC-based toolchain (internal or
    external) for libstdc++. However, a Buildroot external toolchain gets a
    different BR_CROSS_PATH_SUFFIX. Therefore, we can't reuse the
    toolchain-wrapper that gets built for the GCC-based toolchain, but
    instead have to compile an additional clang-specific wrapper, called
    toolchain-wrapper-clang.

 BTW, I've also fixed small typos in the commit messages here and there, and
also some check-package warnings, I'm not going to mention those explicitly.

> Use a post install hook to rename the clang-8 binary to clang-8.br_real
> and recreate all symlinks:
> 
>  # clang -> toolchain-wrapper-clang
>  # clang++ -> toolchain-wrapper-clang
>  # clang-8 -> toolchain-wrapper-clang
>  # clang-8.br_real
>  # clang++.br_real -> clang-8.br_real

 Are these *.br_real -> clang-8.br_real symlinks useful for anything? I don't
think so, since nobody "knows" that clang++.br_real even exists.

>  # clang.br_real -> clang-8.br_real
>  # clang-cl -> toolchain-wrapper-clang
>  # clang-cl.br_real -> clang-8.br_real
>  # clang-cpp -> toolchain-wrapper-clang
>  # clang-cpp.br_real -> clang-8.br_real
[snip]
> +define HOST_CLANG_INSTALL_WRAPPER_AND_SIMPLE_SYMLINKS
> +	$(Q)cd $(HOST_DIR)/bin; \
> +	for i in clang clang-$(CLANG_VERSION_MAJOR) clang++ clang-cl clang-cpp; do \
> +		case "$$i" in \
> +		*clang-$(CLANG_VERSION_MAJOR)) \

 This loop with cases is not needed here. With gcc and friends, we need it
because we loop over a wildcard. Here, however, we know exactly what we loop
over. So it's much simpler to move this outside of the loop.

> +			rm -f $$i.br_real; \
> +			mv $$i $$i.br_real; \
> +			ln -sf toolchain-wrapper-clang $$i; \
> +			;; \
> +		*) \
> +			ln -snf toolchain-wrapper-clang $$i; \
> +			ln -snf clang-$(CLANG_VERSION_MAJOR).br_real $$i.br_real; \

 Given the remark above, I removed this line.

 Regards,
 Arnout

> +			;; \
> +		esac; \
> +	done
> +endef
> +
> +define HOST_CLANG_TOOLCHAIN_WRAPPER_BUILD
> +	$(HOSTCC) $(HOST_CFLAGS) $(TOOLCHAIN_WRAPPER_ARGS) \
> +		-s -Wl,--hash-style=$(TOOLCHAIN_WRAPPER_HASH_STYLE) \
> +		toolchain/toolchain-wrapper.c \
> +		-o $(@D)/toolchain-wrapper-clang
> +endef
> +
> +define HOST_CLANG_TOOLCHAIN_WRAPPER_INSTALL
> +	$(INSTALL) -D -m 0755 $(@D)/toolchain-wrapper-clang \
> +		$(HOST_DIR)/bin/toolchain-wrapper-clang
> +endef
> +
> +HOST_CLANG_TOOLCHAIN_WRAPPER_ARGS += -DBR_CROSS_PATH_SUFFIX='".br_real"'
> +HOST_CLANG_POST_BUILD_HOOKS += HOST_CLANG_TOOLCHAIN_WRAPPER_BUILD
> +HOST_CLANG_POST_INSTALL_HOOKS += HOST_CLANG_TOOLCHAIN_WRAPPER_INSTALL
> +HOST_CLANG_POST_INSTALL_HOOKS += HOST_CLANG_INSTALL_WRAPPER_AND_SIMPLE_SYMLINKS

[Buildroot] [PATCH v2 05/12] linux: override CC for the case CC is not GCC

[Romain Naour]

Until now we provided only CROSS_COMPILE to the kernel
buildsystem to use our GCC cross-compiler. Internally,
the buildsystem defined CC=$(CROSS_COMPILE)gcc.

Since Clang can now be used as cross-compiler, Buildroot
may define in the future TARGET_CC to use clang instead
of GCC.

In order to build the kernel with the selected compiler,
make sure to define CC=$(TARGET_CC) in LINUX_MAKE_FLAGS.

Signed-off-by: Romain Naour <romain.naour@smile.fr>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Valentin Korenblit <valentinkorenblit@gmail.com>
---
 linux/linux.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/linux/linux.mk b/linux/linux.mk
index 29d2f0ee69..d381c96d85 100644
--- a/linux/linux.mk
+++ b/linux/linux.mk
@@ -128,6 +128,7 @@ LINUX_MAKE_FLAGS = \
 	ARCH=$(KERNEL_ARCH) \
 	INSTALL_MOD_PATH=$(TARGET_DIR) \
 	CROSS_COMPILE="$(TARGET_CROSS)" \
+	CC="$(TARGET_CC)" \
 	DEPMOD=$(HOST_DIR)/sbin/depmod
 
 ifeq ($(BR2_REPRODUCIBLE),y)
-- 
2.21.0

[Buildroot] [PATCH v2 05/12] linux: override CC for the case CC is not GCC

[Arnout Vandecappelle]

On 07/09/2019 11:40, Romain Naour wrote:
> Until now we provided only CROSS_COMPILE to the kernel
> buildsystem to use our GCC cross-compiler. Internally,
> the buildsystem defined CC=$(CROSS_COMPILE)gcc.

 I don't like that we have to patch every package that happens to refer to
gcc... Note that we have roughly 70 packages that use CROSS_COMPILE, so unless
you checked all of them, it is likely that some of them are still referring to
gcc as well (most of them probably not because we set CC=... in
TARGET_CONFIGURE_OPTS, which gets used by most packages (but not by linux.mk)).

 Therefore, maybe a better alternative is to lie to the packages :-) We can
symlink gcc etc. to clang instead of the toolchain wrapper. Then we just have to
find a way to convert g++ to clang++ etc, but note that clang behaves correctly
when called as aarch64-none-linux-gnu-g++ (i.e. it acts as if it was called
through clang-c++), so we can probably work with that.

 Regards,
 Arnout


> Since Clang can now be used as cross-compiler, Buildroot
> may define in the future TARGET_CC to use clang instead
> of GCC.
> 
> In order to build the kernel with the selected compiler,
> make sure to define CC=$(TARGET_CC) in LINUX_MAKE_FLAGS.
> 
> Signed-off-by: Romain Naour <romain.naour@smile.fr>
> Cc: Matt Weber <matthew.weber@rockwellcollins.com>
> Cc: Valentin Korenblit <valentinkorenblit@gmail.com>
> ---
>  linux/linux.mk | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/linux/linux.mk b/linux/linux.mk
> index 29d2f0ee69..d381c96d85 100644
> --- a/linux/linux.mk
> +++ b/linux/linux.mk
> @@ -128,6 +128,7 @@ LINUX_MAKE_FLAGS = \
>  	ARCH=$(KERNEL_ARCH) \
>  	INSTALL_MOD_PATH=$(TARGET_DIR) \
>  	CROSS_COMPILE="$(TARGET_CROSS)" \
> +	CC="$(TARGET_CC)" \
>  	DEPMOD=$(HOST_DIR)/sbin/depmod
>  
>  ifeq ($(BR2_REPRODUCIBLE),y)
> 

[Buildroot] [PATCH v2 06/12] package/meson: use TARGET_{CC, CXX} instead of TARGET_CROSS for cc and cpp

[Romain Naour]

Using TARGET_CROSS expect using GCC compiler, instead use
TARGET_CC and TARGET_CXX for the case where Clang is
used as cross-compiler.

Signed-off-by: Romain Naour <romain.naour@smile.fr>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Valentin Korenblit <valentinkorenblit@gmail.com>
---
v2: fix pkg-meson (missing $) and keep TARGET_CROSS in sed command for other tools (as etc).
---
 package/meson/cross-compilation.conf.in | 4 ++--
 package/meson/meson.mk                  | 2 ++
 package/pkg-meson.mk                    | 2 ++
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/package/meson/cross-compilation.conf.in b/package/meson/cross-compilation.conf.in
index fc8e27f7eb..86347e9e4e 100644
--- a/package/meson/cross-compilation.conf.in
+++ b/package/meson/cross-compilation.conf.in
@@ -4,8 +4,8 @@
 # - Buildroot's 'target' is Meson's 'host'
 
 [binaries]
-c = '@TARGET_CROSS at gcc'
-cpp = '@TARGET_CROSS at g++'
+c = '@TARGET_CC@'
+cpp = '@TARGET_CXX@'
 ar = '@TARGET_CROSS at ar'
 strip = '@TARGET_CROSS at strip'
 pkgconfig = '@HOST_DIR@/usr/bin/pkg-config'
diff --git a/package/meson/meson.mk b/package/meson/meson.mk
index 3267581fc6..6b4491d24f 100644
--- a/package/meson/meson.mk
+++ b/package/meson/meson.mk
@@ -55,6 +55,8 @@ HOST_MESON_SED_CXXFLAGS = $(if $(strip $(TARGET_CXXFLAGS)),`printf '"%s"$(comma)
 define HOST_MESON_INSTALL_CROSS_CONF
 	mkdir -p $(HOST_DIR)/etc/meson
 	sed -e "s%@TARGET_CROSS@%$(TARGET_CROSS)%g" \
+	    -e "s%@TARGET_CC@%$(TARGET_CC)%g" \
+	    -e "s%@TARGET_CXX@%$(TARGET_CXX)%g" \
 	    -e "s%@TARGET_ARCH@%$(HOST_MESON_TARGET_CPU_FAMILY)%g" \
 	    -e "s%@TARGET_CPU@%$(HOST_MESON_TARGET_CPU)%g" \
 	    -e "s%@TARGET_ENDIAN@%$(HOST_MESON_TARGET_ENDIAN)%g" \
diff --git a/package/pkg-meson.mk b/package/pkg-meson.mk
index 0b811d1cc0..e035dd1722 100644
--- a/package/pkg-meson.mk
+++ b/package/pkg-meson.mk
@@ -72,6 +72,8 @@ define $(2)_CONFIGURE_CMDS
 	rm -rf $$($$(PKG)_SRCDIR)/build
 	mkdir -p $$($$(PKG)_SRCDIR)/build
 	sed -e "s%@TARGET_CROSS@%$$(TARGET_CROSS)%g" \
+	    -e "s%@TARGET_CC@%$$(TARGET_CC)%g" \
+	    -e "s%@TARGET_CXX@%$$(TARGET_CXX)%g" \
 	    -e "s%@TARGET_ARCH@%$$(HOST_MESON_TARGET_CPU_FAMILY)%g" \
 	    -e "s%@TARGET_CPU@%$$(GCC_TARGET_CPU)%g" \
 	    -e "s%@TARGET_ENDIAN@%$$(call LOWERCASE,$$(BR2_ENDIAN))%g" \
-- 
2.21.0

[Buildroot] [PATCH v2 07/12] package/busybox: fix applets runtime issue when building with clang cross-compiler

[Romain Naour]

Apply a patch contributed by Luis Marques on the Busybox mailing list [1]
fixing a runtime issue (segfault) when busybox is compiled by Clang.

The patch disable the compiler optimizations for Clang/LLVM only.

Without this patch, busybox segfault with several applets
(login on aarch64 using Clang 8.0.1, init on x86_64 using Clang 9.0.0rc3)

[1] http://lists.busybox.net/pipermail/busybox/2019-June/087337.html

Signed-off-by: Romain Naour <romain.naour@smile.fr>
Cc: Luis Marques <luismarques@lowrisc.org>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Valentin Korenblit <valentinkorenblit@gmail.com>
---
Note:
 The Luis Marques's SoB line in the Busybox patch is missing.
 The patch is still under review to avoid disabling optimizations.
---
 ...use-BB_GLOBAL_CONST-where-applicable.patch | 173 ++++++++++++++++++
 1 file changed, 173 insertions(+)
 create mode 100644 package/busybox/0003-use-BB_GLOBAL_CONST-where-applicable.patch

diff --git a/package/busybox/0003-use-BB_GLOBAL_CONST-where-applicable.patch b/package/busybox/0003-use-BB_GLOBAL_CONST-where-applicable.patch
new file mode 100644
index 0000000000..738a15b0de
--- /dev/null
+++ b/package/busybox/0003-use-BB_GLOBAL_CONST-where-applicable.patch
@@ -0,0 +1,173 @@
+From 6f53fa8303edff685aee3cc16a6c8967fae869db Mon Sep 17 00:00:00 2001
+From: Luis Marques <luismarques@lowrisc.org>
+Date: Wed, 4 Sep 2019 17:48:39 +0200
+Subject: [PATCH] use BB_GLOBAL_CONST where applicable
+
+Signed-off-by: Romain Naour <romain.naour@smile.fr>
+---
+ coreutils/test.c          |  3 +--
+ coreutils/test_ptr_hack.c |  2 +-
+ include/libbb.h           | 27 +++++++++++++++++++++++++--
+ libbb/lineedit.c          |  3 +--
+ libbb/lineedit_ptr_hack.c |  2 +-
+ libbb/ptr_to_globals.c    |  2 +-
+ shell/ash.c               | 13 -------------
+ shell/ash_ptr_hack.c      |  6 +++---
+ 8 files changed, 33 insertions(+), 25 deletions(-)
+
+diff --git a/coreutils/test.c b/coreutils/test.c
+index 8d7dac025..e1d440106 100644
+--- a/coreutils/test.c
++++ b/coreutils/test.c
+@@ -400,8 +400,7 @@ struct test_statics {
+ 	jmp_buf leaving;
+ };
+ 
+-/* See test_ptr_hack.c */
+-extern struct test_statics *const test_ptr_to_statics;
++extern struct test_statics *BB_GLOBAL_CONST test_ptr_to_statics;
+ 
+ #define S (*test_ptr_to_statics)
+ #define args            (S.args         )
+diff --git a/coreutils/test_ptr_hack.c b/coreutils/test_ptr_hack.c
+index 5ba9dcc68..6759b2144 100644
+--- a/coreutils/test_ptr_hack.c
++++ b/coreutils/test_ptr_hack.c
+@@ -18,6 +18,6 @@ struct test_statics *test_ptr_to_statics;
+ /* gcc -combine will see through and complain */
+ /* Using alternative method which is more likely to break
+  * on weird architectures, compilers, linkers and so on */
+-struct test_statics *const test_ptr_to_statics __attribute__ ((section (".data")));
++struct test_statics *BB_GLOBAL_CONST test_ptr_to_statics __attribute__ ((section (".data")));
+ 
+ #endif
+diff --git a/include/libbb.h b/include/libbb.h
+index 021100db1..2523fd89c 100644
+--- a/include/libbb.h
++++ b/include/libbb.h
+@@ -338,10 +338,33 @@ struct BUG_off_t_size_is_misdetected {
+ #endif
+ #endif
+ 
++/* We use a trick to have more optimized code (fewer pointer reloads). E.g.:
++ *  ash.c:   extern struct globals *const ash_ptr_to_globals;
++ *  ash_ptr_hack.c: struct globals *ash_ptr_to_globals;
++ * This way, compiler in ash.c knows the pointer cannot change.
++ *
++ * However, this relies on C undefined behavior, so we whitelist compilers
++ * where we know this isn't problematic, by using the the BB_GLOBAL_CONST
++ * preprocessor definition.
++ * If you are sure this trick also works with your toolchain you can add
++ * "-DBB_GLOBAL_CONST='const'" to CONFIG_EXTRA_CFLAGS or add your compiler to
++ * the whitelist below.
++ */
++
++#ifndef BB_GLOBAL_CONST
++# if defined(__clang__)
++#  define BB_GLOBAL_CONST
++# elif defined(__GNUC__)
++#  define BB_GLOBAL_CONST const
++# else
++#  define BB_GLOBAL_CONST
++# endif
++#endif
++
+ #if defined(__GLIBC__)
+ /* glibc uses __errno_location() to get a ptr to errno */
+ /* We can just memorize it once - no multithreading in busybox :) */
+-extern int *const bb_errno;
++extern int *BB_GLOBAL_CONST bb_errno;
+ #undef errno
+ #define errno (*bb_errno)
+ #endif
+@@ -2109,7 +2132,7 @@ struct globals;
+ /* '*const' ptr makes gcc optimize code much better.
+  * Magic prevents ptr_to_globals from going into rodata.
+  * If you want to assign a value, use SET_PTR_TO_GLOBALS(x) */
+-extern struct globals *const ptr_to_globals;
++extern struct globals *BB_GLOBAL_CONST ptr_to_globals;
+ /* At least gcc 3.4.6 on mipsel system needs optimization barrier */
+ #define barrier() __asm__ __volatile__("":::"memory")
+ #define SET_PTR_TO_GLOBALS(x) do { \
+diff --git a/libbb/lineedit.c b/libbb/lineedit.c
+index fbabc6c12..b9e9719c5 100644
+--- a/libbb/lineedit.c
++++ b/libbb/lineedit.c
+@@ -180,8 +180,7 @@ struct lineedit_statics {
+ #endif
+ };
+ 
+-/* See lineedit_ptr_hack.c */
+-extern struct lineedit_statics *const lineedit_ptr_to_statics;
++extern struct lineedit_statics *BB_GLOBAL_CONST lineedit_ptr_to_statics;
+ 
+ #define S (*lineedit_ptr_to_statics)
+ #define state            (S.state           )
+diff --git a/libbb/lineedit_ptr_hack.c b/libbb/lineedit_ptr_hack.c
+index dc45855d5..ac33bd409 100644
+--- a/libbb/lineedit_ptr_hack.c
++++ b/libbb/lineedit_ptr_hack.c
+@@ -18,6 +18,6 @@ struct lineedit_statics *lineedit_ptr_to_statics;
+ /* gcc -combine will see through and complain */
+ /* Using alternative method which is more likely to break
+  * on weird architectures, compilers, linkers and so on */
+-struct lineedit_statics *const lineedit_ptr_to_statics __attribute__ ((section (".data")));
++struct lineedit_statics *BB_GLOBAL_CONST lineedit_ptr_to_statics __attribute__ ((section (".data")));
+ 
+ #endif
+diff --git a/libbb/ptr_to_globals.c b/libbb/ptr_to_globals.c
+index 8ba9cd154..26d7b2042 100644
+--- a/libbb/ptr_to_globals.c
++++ b/libbb/ptr_to_globals.c
+@@ -25,7 +25,7 @@ int *bb_errno;
+ /* gcc -combine will see through and complain */
+ /* Using alternative method which is more likely to break
+  * on weird architectures, compilers, linkers and so on */
+-struct globals *const ptr_to_globals __attribute__ ((section (".data")));
++struct globals *BB_GLOBAL_CONST ptr_to_globals __attribute__ ((section (".data")));
+ 
+ #ifdef __GLIBC__
+ int *const bb_errno __attribute__ ((section (".data")));
+diff --git a/shell/ash.c b/shell/ash.c
+index e3bbac9a0..3141f3812 100644
+--- a/shell/ash.c
++++ b/shell/ash.c
+@@ -288,19 +288,6 @@ typedef long arith_t;
+ # error "Do not even bother, ash will not run on NOMMU machine"
+ #endif
+ 
+-/* We use a trick to have more optimized code (fewer pointer reloads):
+- *  ash.c:   extern struct globals *const ash_ptr_to_globals;
+- *  ash_ptr_hack.c: struct globals *ash_ptr_to_globals;
+- * This way, compiler in ash.c knows the pointer can not change.
+- *
+- * However, this may break on weird arches or toolchains. In this case,
+- * set "-DBB_GLOBAL_CONST=''" in CONFIG_EXTRA_CFLAGS to disable
+- * this optimization.
+- */
+-#ifndef BB_GLOBAL_CONST
+-# define BB_GLOBAL_CONST const
+-#endif
+-
+ 
+ /* ============ Hash table sizes. Configurable. */
+ 
+diff --git a/shell/ash_ptr_hack.c b/shell/ash_ptr_hack.c
+index f69840825..af16cca27 100644
+--- a/shell/ash_ptr_hack.c
++++ b/shell/ash_ptr_hack.c
+@@ -22,8 +22,8 @@ struct globals_var      *ash_ptr_to_globals_var;
+ /* gcc -combine will see through and complain */
+ /* Using alternative method which is more likely to break
+  * on weird architectures, compilers, linkers and so on */
+-struct globals_misc     *const ash_ptr_to_globals_misc __attribute__ ((section (".data")));
+-struct globals_memstack *const ash_ptr_to_globals_memstack __attribute__ ((section (".data")));
+-struct globals_var      *const ash_ptr_to_globals_var __attribute__ ((section (".data")));
++struct globals_misc     *BB_GLOBAL_CONST ash_ptr_to_globals_misc __attribute__ ((section (".data")));
++struct globals_memstack *BB_GLOBAL_CONST ash_ptr_to_globals_memstack __attribute__ ((section (".data")));
++struct globals_var      *BB_GLOBAL_CONST ash_ptr_to_globals_var __attribute__ ((section (".data")));
+ 
+ #endif
+-- 
+2.21.0
+
-- 
2.21.0

[Buildroot] [PATCH v2 07/12] package/busybox: fix applets runtime issue when building with clang cross-compiler

[Matthew Weber]

Romain,

On Sat, Sep 7, 2019 at 4:40 AM Romain Naour <romain.naour@smile.fr> wrote:
>
> Apply a patch contributed by Luis Marques on the Busybox mailing list [1]
> fixing a runtime issue (segfault) when busybox is compiled by Clang.
>
> The patch disable the compiler optimizations for Clang/LLVM only.
>
> Without this patch, busybox segfault with several applets
> (login on aarch64 using Clang 8.0.1, init on x86_64 using Clang 9.0.0rc3)
>
> [1] http://lists.busybox.net/pipermail/busybox/2019-June/087337.html
>
> Signed-off-by: Romain Naour <romain.naour@smile.fr>
> Cc: Luis Marques <luismarques@lowrisc.org>
> Cc: Matt Weber <matthew.weber@rockwellcollins.com>

Did a build time test using the qemu aarch64 configuration, selecting
the prebuilt external toolchain and enabling the Clang as
cross-compiler option.
I then booted this configuration in qemu and logged in.
# dmesg | grep clang
Linux version 4.19.16 (mlweber1 at fooobar) (clang version 8.0.1
(tags/RELEASE_801/final)) #1 SMP Mon Sep 9 09:25:19 CDT 2019
#

Tested-by: Matt Weber <matthew.weber@rockwellcollins.com>


> Cc: Valentin Korenblit <valentinkorenblit@gmail.com>
> ---
> Note:
>  The Luis Marques's SoB line in the Busybox patch is missing.
>  The patch is still under review to avoid disabling optimizations.
> ---
>  ...use-BB_GLOBAL_CONST-where-applicable.patch | 173 ++++++++++++++++++
>  1 file changed, 173 insertions(+)
>  create mode 100644 package/busybox/0003-use-BB_GLOBAL_CONST-where-applicable.patch
>
> diff --git a/package/busybox/0003-use-BB_GLOBAL_CONST-where-applicable.patch b/package/busybox/0003-use-BB_GLOBAL_CONST-where-applicable.patch
> new file mode 100644
> index 0000000000..738a15b0de
> --- /dev/null
> +++ b/package/busybox/0003-use-BB_GLOBAL_CONST-where-applicable.patch
> @@ -0,0 +1,173 @@
> +From 6f53fa8303edff685aee3cc16a6c8967fae869db Mon Sep 17 00:00:00 2001
> +From: Luis Marques <luismarques@lowrisc.org>
> +Date: Wed, 4 Sep 2019 17:48:39 +0200
> +Subject: [PATCH] use BB_GLOBAL_CONST where applicable
> +
> +Signed-off-by: Romain Naour <romain.naour@smile.fr>
> +---
> + coreutils/test.c          |  3 +--
> + coreutils/test_ptr_hack.c |  2 +-
> + include/libbb.h           | 27 +++++++++++++++++++++++++--
> + libbb/lineedit.c          |  3 +--
> + libbb/lineedit_ptr_hack.c |  2 +-
> + libbb/ptr_to_globals.c    |  2 +-
> + shell/ash.c               | 13 -------------
> + shell/ash_ptr_hack.c      |  6 +++---
> + 8 files changed, 33 insertions(+), 25 deletions(-)
> +
> +diff --git a/coreutils/test.c b/coreutils/test.c
> +index 8d7dac025..e1d440106 100644
> +--- a/coreutils/test.c
> ++++ b/coreutils/test.c
> +@@ -400,8 +400,7 @@ struct test_statics {
> +       jmp_buf leaving;
> + };
> +
> +-/* See test_ptr_hack.c */
> +-extern struct test_statics *const test_ptr_to_statics;
> ++extern struct test_statics *BB_GLOBAL_CONST test_ptr_to_statics;
> +
> + #define S (*test_ptr_to_statics)
> + #define args            (S.args         )
> +diff --git a/coreutils/test_ptr_hack.c b/coreutils/test_ptr_hack.c
> +index 5ba9dcc68..6759b2144 100644
> +--- a/coreutils/test_ptr_hack.c
> ++++ b/coreutils/test_ptr_hack.c
> +@@ -18,6 +18,6 @@ struct test_statics *test_ptr_to_statics;
> + /* gcc -combine will see through and complain */
> + /* Using alternative method which is more likely to break
> +  * on weird architectures, compilers, linkers and so on */
> +-struct test_statics *const test_ptr_to_statics __attribute__ ((section (".data")));
> ++struct test_statics *BB_GLOBAL_CONST test_ptr_to_statics __attribute__ ((section (".data")));
> +
> + #endif
> +diff --git a/include/libbb.h b/include/libbb.h
> +index 021100db1..2523fd89c 100644
> +--- a/include/libbb.h
> ++++ b/include/libbb.h
> +@@ -338,10 +338,33 @@ struct BUG_off_t_size_is_misdetected {
> + #endif
> + #endif
> +
> ++/* We use a trick to have more optimized code (fewer pointer reloads). E.g.:
> ++ *  ash.c:   extern struct globals *const ash_ptr_to_globals;
> ++ *  ash_ptr_hack.c: struct globals *ash_ptr_to_globals;
> ++ * This way, compiler in ash.c knows the pointer cannot change.
> ++ *
> ++ * However, this relies on C undefined behavior, so we whitelist compilers
> ++ * where we know this isn't problematic, by using the the BB_GLOBAL_CONST
> ++ * preprocessor definition.
> ++ * If you are sure this trick also works with your toolchain you can add
> ++ * "-DBB_GLOBAL_CONST='const'" to CONFIG_EXTRA_CFLAGS or add your compiler to
> ++ * the whitelist below.
> ++ */
> ++
> ++#ifndef BB_GLOBAL_CONST
> ++# if defined(__clang__)
> ++#  define BB_GLOBAL_CONST
> ++# elif defined(__GNUC__)
> ++#  define BB_GLOBAL_CONST const
> ++# else
> ++#  define BB_GLOBAL_CONST
> ++# endif
> ++#endif
> ++
> + #if defined(__GLIBC__)
> + /* glibc uses __errno_location() to get a ptr to errno */
> + /* We can just memorize it once - no multithreading in busybox :) */
> +-extern int *const bb_errno;
> ++extern int *BB_GLOBAL_CONST bb_errno;
> + #undef errno
> + #define errno (*bb_errno)
> + #endif
> +@@ -2109,7 +2132,7 @@ struct globals;
> + /* '*const' ptr makes gcc optimize code much better.
> +  * Magic prevents ptr_to_globals from going into rodata.
> +  * If you want to assign a value, use SET_PTR_TO_GLOBALS(x) */
> +-extern struct globals *const ptr_to_globals;
> ++extern struct globals *BB_GLOBAL_CONST ptr_to_globals;
> + /* At least gcc 3.4.6 on mipsel system needs optimization barrier */
> + #define barrier() __asm__ __volatile__("":::"memory")
> + #define SET_PTR_TO_GLOBALS(x) do { \
> +diff --git a/libbb/lineedit.c b/libbb/lineedit.c
> +index fbabc6c12..b9e9719c5 100644
> +--- a/libbb/lineedit.c
> ++++ b/libbb/lineedit.c
> +@@ -180,8 +180,7 @@ struct lineedit_statics {
> + #endif
> + };
> +
> +-/* See lineedit_ptr_hack.c */
> +-extern struct lineedit_statics *const lineedit_ptr_to_statics;
> ++extern struct lineedit_statics *BB_GLOBAL_CONST lineedit_ptr_to_statics;
> +
> + #define S (*lineedit_ptr_to_statics)
> + #define state            (S.state           )
> +diff --git a/libbb/lineedit_ptr_hack.c b/libbb/lineedit_ptr_hack.c
> +index dc45855d5..ac33bd409 100644
> +--- a/libbb/lineedit_ptr_hack.c
> ++++ b/libbb/lineedit_ptr_hack.c
> +@@ -18,6 +18,6 @@ struct lineedit_statics *lineedit_ptr_to_statics;
> + /* gcc -combine will see through and complain */
> + /* Using alternative method which is more likely to break
> +  * on weird architectures, compilers, linkers and so on */
> +-struct lineedit_statics *const lineedit_ptr_to_statics __attribute__ ((section (".data")));
> ++struct lineedit_statics *BB_GLOBAL_CONST lineedit_ptr_to_statics __attribute__ ((section (".data")));
> +
> + #endif
> +diff --git a/libbb/ptr_to_globals.c b/libbb/ptr_to_globals.c
> +index 8ba9cd154..26d7b2042 100644
> +--- a/libbb/ptr_to_globals.c
> ++++ b/libbb/ptr_to_globals.c
> +@@ -25,7 +25,7 @@ int *bb_errno;
> + /* gcc -combine will see through and complain */
> + /* Using alternative method which is more likely to break
> +  * on weird architectures, compilers, linkers and so on */
> +-struct globals *const ptr_to_globals __attribute__ ((section (".data")));
> ++struct globals *BB_GLOBAL_CONST ptr_to_globals __attribute__ ((section (".data")));
> +
> + #ifdef __GLIBC__
> + int *const bb_errno __attribute__ ((section (".data")));
> +diff --git a/shell/ash.c b/shell/ash.c
> +index e3bbac9a0..3141f3812 100644
> +--- a/shell/ash.c
> ++++ b/shell/ash.c
> +@@ -288,19 +288,6 @@ typedef long arith_t;
> + # error "Do not even bother, ash will not run on NOMMU machine"
> + #endif
> +
> +-/* We use a trick to have more optimized code (fewer pointer reloads):
> +- *  ash.c:   extern struct globals *const ash_ptr_to_globals;
> +- *  ash_ptr_hack.c: struct globals *ash_ptr_to_globals;
> +- * This way, compiler in ash.c knows the pointer can not change.
> +- *
> +- * However, this may break on weird arches or toolchains. In this case,
> +- * set "-DBB_GLOBAL_CONST=''" in CONFIG_EXTRA_CFLAGS to disable
> +- * this optimization.
> +- */
> +-#ifndef BB_GLOBAL_CONST
> +-# define BB_GLOBAL_CONST const
> +-#endif
> +-
> +
> + /* ============ Hash table sizes. Configurable. */
> +
> +diff --git a/shell/ash_ptr_hack.c b/shell/ash_ptr_hack.c
> +index f69840825..af16cca27 100644
> +--- a/shell/ash_ptr_hack.c
> ++++ b/shell/ash_ptr_hack.c
> +@@ -22,8 +22,8 @@ struct globals_var      *ash_ptr_to_globals_var;
> + /* gcc -combine will see through and complain */
> + /* Using alternative method which is more likely to break
> +  * on weird architectures, compilers, linkers and so on */
> +-struct globals_misc     *const ash_ptr_to_globals_misc __attribute__ ((section (".data")));
> +-struct globals_memstack *const ash_ptr_to_globals_memstack __attribute__ ((section (".data")));
> +-struct globals_var      *const ash_ptr_to_globals_var __attribute__ ((section (".data")));
> ++struct globals_misc     *BB_GLOBAL_CONST ash_ptr_to_globals_misc __attribute__ ((section (".data")));
> ++struct globals_memstack *BB_GLOBAL_CONST ash_ptr_to_globals_memstack __attribute__ ((section (".data")));
> ++struct globals_var      *BB_GLOBAL_CONST ash_ptr_to_globals_var __attribute__ ((section (".data")));
> +
> + #endif
> +--
> +2.21.0
> +
> --
> 2.21.0
>


--

Matthew Weber | Associate Director Software Engineer | Commercial Avionics

COLLINS AEROSPACE

400 Collins Road NE, Cedar Rapids, Iowa 52498, USA

Tel: +1 319 295 7349 | FAX: +1 319 263 6099

matthew.weber at collins.com | collinsaerospace.com



CONFIDENTIALITY WARNING: This message may contain proprietary and/or
privileged information of Collins Aerospace and its affiliated
companies. If you are not the intended recipient, please 1) Do not
disclose, copy, distribute or use this message or its contents. 2)
Advise the sender by return email. 3) Delete all copies (including all
attachments) from your computer. Your cooperation is greatly
appreciated.


Any export restricted material should be shared using my
matthew.weber at corp.rockwellcollins.com address.

[Buildroot] [PATCH v2 07/12] package/busybox: fix applets runtime issue when building with clang cross-compiler

[Arnout Vandecappelle]

On 07/09/2019 11:40, Romain Naour wrote:
> Apply a patch contributed by Luis Marques on the Busybox mailing list [1]
> fixing a runtime issue (segfault) when busybox is compiled by Clang.
> 
> The patch disable the compiler optimizations for Clang/LLVM only.
> 
> Without this patch, busybox segfault with several applets
> (login on aarch64 using Clang 8.0.1, init on x86_64 using Clang 9.0.0rc3)

 We should probably check if this patch is still needed with current busybox.

 Regards,
 Arnout

[Buildroot] [PATCH v2 07/12] package/busybox: fix applets runtime issue when building with clang cross-compiler

[Romain Naour]

Le 29/08/2020 ? 22:21, Arnout Vandecappelle a ?crit?:
> 
> 
> On 07/09/2019 11:40, Romain Naour wrote:
>> Apply a patch contributed by Luis Marques on the Busybox mailing list [1]
>> fixing a runtime issue (segfault) when busybox is compiled by Clang.
>>
>> The patch disable the compiler optimizations for Clang/LLVM only.
>>
>> Without this patch, busybox segfault with several applets
>> (login on aarch64 using Clang 8.0.1, init on x86_64 using Clang 9.0.0rc3)
> 
>  We should probably check if this patch is still needed with current busybox.

It should be fixed with the latest version of busybox 1.32 but it didn't work
well while testing with riscv64 and llvm/clang 10. I need to test again with
aarch64.

https://git.busybox.net/busybox/commit/?id=af7169b4a70eb3f60555ced17a40780f70aaaa5c

Best regards,
Romain


> 
>  Regards,
>  Arnout
> 

[Buildroot] [PATCH v2 08/12] package/clang: add a host entry for clang

[Romain Naour]

In order to allow Buildroot's user to select clang
as cross-compiler we need first an option to select
host-clang package in menuconfig.

Signed-off-by: Romain Naour <romain.naour@smile.fr>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Valentin Korenblit <valentinkorenblit@gmail.com>
---
 package/Config.in.host       |  1 +
 package/clang/Config.in.host | 19 +++++++++++++++++++
 2 files changed, 20 insertions(+)
 create mode 100644 package/clang/Config.in.host

diff --git a/package/Config.in.host b/package/Config.in.host
index 93822304e9..182e175a78 100644
--- a/package/Config.in.host
+++ b/package/Config.in.host
@@ -7,6 +7,7 @@ menu "Host utilities"
 	source "package/cbootimage/Config.in.host"
 	source "package/checkpolicy/Config.in.host"
 	source "package/checksec/Config.in.host"
+	source "package/clang/Config.in.host"
 	source "package/cmake/Config.in.host"
 	source "package/cramfs/Config.in.host"
 	source "package/cryptsetup/Config.in.host"
diff --git a/package/clang/Config.in.host b/package/clang/Config.in.host
new file mode 100644
index 0000000000..ca5d7ba678
--- /dev/null
+++ b/package/clang/Config.in.host
@@ -0,0 +1,19 @@
+config BR2_PACKAGE_HOST_CLANG
+	bool "clang cross-compiler"
+	depends on BR2_PACKAGE_LLVM_ARCH_SUPPORTS
+	depends on BR2_HOST_GCC_AT_LEAST_4_8
+	depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_8
+	depends on BR2_TOOLCHAIN_HAS_THREADS
+	depends on BR2_INSTALL_LIBSTDCPP
+	depends on !BR2_TOOLCHAIN_HAS_GCC_BUG_64735 # std::shared_future
+	depends on !BR2_STATIC_LIBS
+	depends on BR2_USE_WCHAR # std::wstring
+	help
+	  Clang is a C/C++, Objective C/C++ and OpenCL C front-end
+	  for the LLVM compiler.
+
+	  This option install the clang cross-compiler and it's
+	  libraires. It doesn't mean that's used by Buildroot
+	  infra to build packages.
+
+	  http://clang.llvm.org
-- 
2.21.0

[Buildroot] [PATCH v2 08/12] package/clang: add a host entry for clang

[Arnout Vandecappelle]

On 07/09/2019 11:40, Romain Naour wrote:
> In order to allow Buildroot's user to select clang
> as cross-compiler we need first an option to select
> host-clang package in menuconfig.
> 
> Signed-off-by: Romain Naour <romain.naour@smile.fr>
> Cc: Matt Weber <matthew.weber@rockwellcollins.com>
> Cc: Valentin Korenblit <valentinkorenblit@gmail.com>
> ---
>  package/Config.in.host       |  1 +
>  package/clang/Config.in.host | 19 +++++++++++++++++++
>  2 files changed, 20 insertions(+)
>  create mode 100644 package/clang/Config.in.host
> 
> diff --git a/package/Config.in.host b/package/Config.in.host
> index 93822304e9..182e175a78 100644
> --- a/package/Config.in.host
> +++ b/package/Config.in.host
> @@ -7,6 +7,7 @@ menu "Host utilities"
>  	source "package/cbootimage/Config.in.host"
>  	source "package/checkpolicy/Config.in.host"
>  	source "package/checksec/Config.in.host"
> +	source "package/clang/Config.in.host"
>  	source "package/cmake/Config.in.host"
>  	source "package/cramfs/Config.in.host"
>  	source "package/cryptsetup/Config.in.host"
> diff --git a/package/clang/Config.in.host b/package/clang/Config.in.host
> new file mode 100644
> index 0000000000..ca5d7ba678
> --- /dev/null
> +++ b/package/clang/Config.in.host
> @@ -0,0 +1,19 @@
> +config BR2_PACKAGE_HOST_CLANG
> +	bool "clang cross-compiler"
> +	depends on BR2_PACKAGE_LLVM_ARCH_SUPPORTS
> +	depends on BR2_HOST_GCC_AT_LEAST_4_8
> +	depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_8
> +	depends on BR2_TOOLCHAIN_HAS_THREADS
> +	depends on BR2_INSTALL_LIBSTDCPP
> +	depends on !BR2_TOOLCHAIN_HAS_GCC_BUG_64735 # std::shared_future
> +	depends on !BR2_STATIC_LIBS
> +	depends on BR2_USE_WCHAR # std::wstring

 I suppose you blindly copied these dependencies from target llvm? I wonder if
they are really relevant for host clang... AFAIU, most of them are limitations
of the LLVM source code itself, but since we don't compile that for the target
here, they shouldn't apply to host-clang. The only one that I imagine really is
necessary, is BR2_TOOLCHAIN_GCC_AT_LEAST_4_8 - IIUC, clang uses libstdc++ from
gcc, and I can imagine that it requires a "high enough" version of it.

 So I would tend to remove all these limitations except the first three, and
just rely on the autobuilders to turn up any problems.

 Regards,
 Arnout

> +	help
> +	  Clang is a C/C++, Objective C/C++ and OpenCL C front-end
> +	  for the LLVM compiler.
> +
> +	  This option install the clang cross-compiler and it's
> +	  libraires. It doesn't mean that's used by Buildroot
> +	  infra to build packages.
> +
> +	  http://clang.llvm.org
> 

[Buildroot] [PATCH v2 09/12] package/glibc: use GCC cross-compiler if Clang is used as cross-compiler

[Romain Naour]

When BR2_USER_HOST_CLANG_AS_CROSS_COMPILER=y (added in the next patch),
TARGET_CONFIGURE_OPTS contains CC, CPP, CXX set to the path to clang
cross-compiler:

TARGET_CC = $(HOST_DIR)/bin/clang
TARGET_CPP = $(HOST_DIR)/bin/clang-cpp
TARGET_CXX = $(HOST_DIR)/bin/clang++

Since Glibc likely need a GCC toolchain to build, explicitely set theses
variables while configuring glibc package (GLIBC_CONFIGURE_CMDS).

Signed-off-by: Romain Naour <romain.naour@smile.fr>
---
 package/glibc/glibc.mk | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/package/glibc/glibc.mk b/package/glibc/glibc.mk
index 9421f9fd81..131439c593 100644
--- a/package/glibc/glibc.mk
+++ b/package/glibc/glibc.mk
@@ -104,11 +104,16 @@ GLIBC_CONF_ENV += ac_cv_prog_MAKE="$(BR2_MAKE)"
 # Note that as mentionned in
 # http://patches.openembedded.org/patch/38849/, glibc must be
 # built with -O2, so we pass our own CFLAGS and CXXFLAGS below.
+# Use GCC cross-compiler if Clang is used as cross-compiler.
 define GLIBC_CONFIGURE_CMDS
 	mkdir -p $(@D)/build
 	# Do the configuration
 	(cd $(@D)/build; \
 		$(TARGET_CONFIGURE_OPTS) \
+		CC="$(TARGET_CROSS)gcc" \
+		GCC="$(TARGET_CROSS)gcc" \
+		CPP="$(TARGET_CROSS)cpp" \
+		CXX="$(TARGET_CROSS)g++" \
 		CFLAGS="-O2 $(GLIBC_EXTRA_CFLAGS)" CPPFLAGS="" \
 		CXXFLAGS="-O2 $(GLIBC_EXTRA_CFLAGS)" \
 		$(GLIBC_CONF_ENV) \
-- 
2.21.0

[Buildroot] [PATCH v2 10/12] core: allow to use Clang as cross-compiler

[Romain Naour]

Add this new experimental option into "Advanced" menu since
we are expecting some build and runtime issues for number of
packages (bootloaders, kernel).

Add host-clang as dependency in toolchain virtual package
in order to be sure that the clang cross-compiler is built
before generating Buildroot.cmake file from an
TOOLCHAIN_CMAKE_INSTALL_FILES hook (defined in cmake package).
Buildroot.cmake can be used by a cmake package as soon as
the toolchain package is installed.

Install the GCC external toolchain before executing
realpath command by adding an explicit dependency on
toolchain-external. Without this dependency, host-clang
may be build before toolchain-external when
BR2_USER_HOST_CLANG_AS_CROSS_COMPILER=y, so the realpath
fail to set GCC_INSTALL_PREFIX leading to
"crtbegin.o no such file or directory" error while linking
applications.

Only Glibc toolchain has been tested.

Signed-off-by: Romain Naour <romain.naour@smile.fr>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Valentin Korenblit <valentinkorenblit@gmail.com>
---
v2: fix typo TOOLCHAIN_{BUILDROOT,EXTERNAL}_DEPENDENCIES in toolchain-external.mk
    Install the GCC external toolchain before executing realpath command.
    Move host-clang dependency to toolchain virtual package since host-clang now
    depends on external-toolchain.
    Add Glibc toolchain dependency
---
 Config.in                        | 23 +++++++++++++++++++++++
 package/Makefile.in              | 13 ++++++++++---
 package/clang/clang.mk           |  7 +++++++
 toolchain/toolchain/toolchain.mk |  7 +++++++
 4 files changed, 47 insertions(+), 3 deletions(-)

diff --git a/Config.in b/Config.in
index a6e280b885..dc2e5f7320 100644
--- a/Config.in
+++ b/Config.in
@@ -711,6 +711,29 @@ config BR2_REPRODUCIBLE
 	  This is labeled as an experimental feature, as not all
 	  packages behave properly to ensure reproducibility.
 
+config BR2_USER_HOST_CLANG_AS_CROSS_COMPILER
+	bool "Use Clang as cross-compiler (experimental)"
+	depends on BR2_TOOLCHAIN_USES_GLIBC
+	depends on BR2_PACKAGE_LLVM_ARCH_SUPPORTS
+	depends on BR2_HOST_GCC_AT_LEAST_4_8
+	depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_8
+	depends on BR2_TOOLCHAIN_HAS_THREADS
+	depends on BR2_INSTALL_LIBSTDCPP
+	depends on !BR2_TOOLCHAIN_HAS_GCC_BUG_64735 # std::shared_future
+	depends on !BR2_STATIC_LIBS
+	depends on BR2_USE_WCHAR # std::wstring
+	select BR2_PACKAGE_HOST_CLANG
+	help
+	  This option will force Buildroot to use Clang as cross-compiler
+	  instead of GCC. A GCC toolchain (internal or external) is still
+	  needed to build with Clang.
+
+	  This is labeled as an experimental feature, since we are
+	  expecting some build and runtime issues for number of packages
+	  (bootloaders, kernel).
+
+	  Note: Only Glibc toolchain has been tested.
+
 endmenu
 
 comment "Security Hardening Options"
diff --git a/package/Makefile.in b/package/Makefile.in
index 0a7899c852..aebf4edd1b 100644
--- a/package/Makefile.in
+++ b/package/Makefile.in
@@ -200,9 +200,6 @@ endif
 # Define TARGET_xx variables for all common binutils/gcc
 TARGET_AR       = $(TARGET_CROSS)ar
 TARGET_AS       = $(TARGET_CROSS)as
-TARGET_CC       = $(TARGET_CROSS)gcc
-TARGET_CPP      = $(TARGET_CROSS)cpp
-TARGET_CXX      = $(TARGET_CROSS)g++
 TARGET_FC       = $(TARGET_CROSS)gfortran
 TARGET_LD       = $(TARGET_CROSS)ld
 TARGET_NM       = $(TARGET_CROSS)nm
@@ -211,6 +208,16 @@ TARGET_READELF  = $(TARGET_CROSS)readelf
 TARGET_OBJCOPY  = $(TARGET_CROSS)objcopy
 TARGET_OBJDUMP  = $(TARGET_CROSS)objdump
 
+ifeq ($(BR2_USER_HOST_CLANG_AS_CROSS_COMPILER),y)
+TARGET_CC       = $(HOST_DIR)/bin/clang
+TARGET_CPP      = $(HOST_DIR)/bin/clang-cpp
+TARGET_CXX      = $(HOST_DIR)/bin/clang++
+else
+TARGET_CC       = $(TARGET_CROSS)gcc
+TARGET_CPP      = $(TARGET_CROSS)cpp
+TARGET_CXX      = $(TARGET_CROSS)g++
+endif
+
 ifeq ($(BR2_STRIP_strip),y)
 STRIP_STRIP_DEBUG := --strip-debug
 TARGET_STRIP = $(TARGET_CROSS)strip
diff --git a/package/clang/clang.mk b/package/clang/clang.mk
index 148df8e611..36703f5d8a 100644
--- a/package/clang/clang.mk
+++ b/package/clang/clang.mk
@@ -14,6 +14,11 @@ CLANG_LICENSE_FILES = LICENSE.TXT
 CLANG_SUPPORTS_IN_SOURCE_BUILD = NO
 CLANG_INSTALL_STAGING = YES
 
+# Allow host-clang to be build as part of the toolchain
+ifeq ($(BR2_USER_HOST_CLANG_AS_CROSS_COMPILER),y)
+HOST_CLANG_ADD_TOOLCHAIN_DEPENDENCY = NO
+endif
+
 HOST_CLANG_DEPENDENCIES = host-llvm host-libxml2
 CLANG_DEPENDENCIES = llvm host-clang
 
@@ -106,7 +111,9 @@ CLANG_CONF_OPTS += -DLLVM_DYLIB_COMPONENTS=all
 # Help host-clang to find our external toolchain, use a relative path from the clang
 # installation directory to the external toolchain installation directory in order to
 # not hardcode the toolchain absolute path.
+# Install the GCC external toolchain before executing realpath command.
 ifeq ($(BR2_TOOLCHAIN_EXTERNAL),y)
+HOST_CLANG_DEPENDENCIES += toolchain-external
 HOST_CLANG_CONF_OPTS += -DGCC_INSTALL_PREFIX:PATH=`realpath --relative-to=$(HOST_DIR)/bin/ $(TOOLCHAIN_EXTERNAL_INSTALL_DIR)`
 endif
 
diff --git a/toolchain/toolchain/toolchain.mk b/toolchain/toolchain/toolchain.mk
index 17fb62147e..d945e27aac 100644
--- a/toolchain/toolchain/toolchain.mk
+++ b/toolchain/toolchain/toolchain.mk
@@ -10,6 +10,13 @@ else ifeq ($(BR2_TOOLCHAIN_EXTERNAL),y)
 TOOLCHAIN_DEPENDENCIES += toolchain-external
 endif
 
+# Make sure the clang cross-compiler is built before
+# generating Buildroot.cmake file from an
+# TOOLCHAIN_CMAKE_INSTALL_FILES hook.
+ifeq ($(BR2_USER_HOST_CLANG_AS_CROSS_COMPILER),y)
+TOOLCHAIN_DEPENDENCIES += host-clang
+endif
+
 TOOLCHAIN_ADD_TOOLCHAIN_DEPENDENCY = NO
 
 # Apply a hack that Rick Felker suggested[1] to avoid conflicts between libc
-- 
2.21.0

[Buildroot] [PATCH v2 10/12] core: allow to use Clang as cross-compiler

[Matthew Weber]

Romain,

On Sat, Sep 7, 2019 at 4:40 AM Romain Naour <romain.naour@smile.fr> wrote:
>
> Add this new experimental option into "Advanced" menu since
> we are expecting some build and runtime issues for number of
> packages (bootloaders, kernel).
>
> Add host-clang as dependency in toolchain virtual package
> in order to be sure that the clang cross-compiler is built
> before generating Buildroot.cmake file from an
> TOOLCHAIN_CMAKE_INSTALL_FILES hook (defined in cmake package).
> Buildroot.cmake can be used by a cmake package as soon as
> the toolchain package is installed.
>
> Install the GCC external toolchain before executing
> realpath command by adding an explicit dependency on
> toolchain-external. Without this dependency, host-clang
> may be build before toolchain-external when
> BR2_USER_HOST_CLANG_AS_CROSS_COMPILER=y, so the realpath
> fail to set GCC_INSTALL_PREFIX leading to
> "crtbegin.o no such file or directory" error while linking
> applications.
>
> Only Glibc toolchain has been tested.
>
> Signed-off-by: Romain Naour <romain.naour@smile.fr>
> Cc: Matt Weber <matthew.weber@rockwellcollins.com>
> Cc: Valentin Korenblit <valentinkorenblit@gmail.com>

Did a build time test using the qemu aarch64 configuration, selecting
the prebuilt external toolchain and enabling the Clang as
cross-compiler option.

Tested-by: Matt Weber <matthew.weber@rockwellcollins.com>

[Buildroot] [PATCH v2 10/12] core: allow to use Clang as cross-compiler

[Arnout Vandecappelle]

 So, this is the one I don't like...

On 07/09/2019 11:40, Romain Naour wrote:
> Add this new experimental option into "Advanced" menu since
> we are expecting some build and runtime issues for number of
> packages (bootloaders, kernel).
> 
> Add host-clang as dependency in toolchain virtual package
> in order to be sure that the clang cross-compiler is built
> before generating Buildroot.cmake file from an
> TOOLCHAIN_CMAKE_INSTALL_FILES hook (defined in cmake package).
> Buildroot.cmake can be used by a cmake package as soon as
> the toolchain package is installed.
> 
> Install the GCC external toolchain before executing
> realpath command by adding an explicit dependency on
> toolchain-external. Without this dependency, host-clang
> may be build before toolchain-external when
> BR2_USER_HOST_CLANG_AS_CROSS_COMPILER=y, so the realpath
> fail to set GCC_INSTALL_PREFIX leading to
> "crtbegin.o no such file or directory" error while linking
> applications.
> 
> Only Glibc toolchain has been tested.

 As far as I understand, the *only* reason we still need GCC is for libgcc and
libstdc++ (and for building glibc). The intention is to build all packages with
clang instead of gcc.

 Therefore, I think it would be better to really treat clang as part of the
internal toolchain. That means:

- In the Config.in, we put it as an option of the internal toolchain. Before the
GCC version, you select clang or GCC. If clang is chosen, we choose a fixed
version of GCC (e.g. our current default).

- In the build, we replace host-gcc-final with host-clang as the
toolchain-buildroot dependency.

 I think that that approach, combined with completely replacing the gcc symlinks
with links to clang, will end up being simpler and more elegant than this patch.
And of course, more user friendly.

 There are two caveats:
- we no longer have an "escape clause" that allows us to build packages with GCC
if they really don't work with clang (except for glibc, but that's part of the
toolchain);
- it might be impossible to build libstdc++ as part of host-gcc-initial, so we
may still need a host-gcc-final stage (or maybe a specific host-gcc-libstdc++)
to build only libstdc++. But I do believe it's possible to build only libstdc++
by simply setting _SUBDIR to libstdc++-v3.

 So it would mean that to use clang as a cross-compiler, you always have to use
an internal toolchain. Later, of course, we should extend this with supporting
clang as an external toolchain as well.

 Also (but again, can be done later), we should revisit the
BR2_TOOLCHAIN_GCC_AT_LEAST_ options. That's actually the toughest one... *Most*
of them are related to the C++ support. Again in most cases, this is provided by
libstdc++ (most language extensions are to the standard library and not to the
core language), but in some cases it may actually depend on the compiler itself.
For the case where it's libstdc++ that is the limitation, we can simply set the
appropriate BR2_TOOLCHAIN_GCC_AT_LEAST_ from clang. For the other cases, we'll
have to add a BR2_TOOLCHAIN_CLANG option, and modify the packages to
BR2_TOOLCHAIN_GCC_AT_LEAST_... || BR2_TOOLCHAIN_CLANG. Except of course that
nobody will notice that it actually works with clang and an older libstdc++, so
that will probably never happen :-). More importantly, though, we can set
!BR2_TOOLCHAIN_CLANG for packages that really don't want clang. And I do prefer
that over falling back to GCC for those packages.

> 
> Signed-off-by: Romain Naour <romain.naour@smile.fr>
> Cc: Matt Weber <matthew.weber@rockwellcollins.com>
> Cc: Valentin Korenblit <valentinkorenblit@gmail.com>
> ---
> v2: fix typo TOOLCHAIN_{BUILDROOT,EXTERNAL}_DEPENDENCIES in toolchain-external.mk
>     Install the GCC external toolchain before executing realpath command.
>     Move host-clang dependency to toolchain virtual package since host-clang now
>     depends on external-toolchain.
>     Add Glibc toolchain dependency
> ---
>  Config.in                        | 23 +++++++++++++++++++++++
>  package/Makefile.in              | 13 ++++++++++---
>  package/clang/clang.mk           |  7 +++++++
>  toolchain/toolchain/toolchain.mk |  7 +++++++
>  4 files changed, 47 insertions(+), 3 deletions(-)
> 
> diff --git a/Config.in b/Config.in
> index a6e280b885..dc2e5f7320 100644
> --- a/Config.in
> +++ b/Config.in
> @@ -711,6 +711,29 @@ config BR2_REPRODUCIBLE
>  	  This is labeled as an experimental feature, as not all
>  	  packages behave properly to ensure reproducibility.
>  
> +config BR2_USER_HOST_CLANG_AS_CROSS_COMPILER
> +	bool "Use Clang as cross-compiler (experimental)"
> +	depends on BR2_TOOLCHAIN_USES_GLIBC
> +	depends on BR2_PACKAGE_LLVM_ARCH_SUPPORTS
> +	depends on BR2_HOST_GCC_AT_LEAST_4_8
> +	depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_8
> +	depends on BR2_TOOLCHAIN_HAS_THREADS
> +	depends on BR2_INSTALL_LIBSTDCPP
> +	depends on !BR2_TOOLCHAIN_HAS_GCC_BUG_64735 # std::shared_future
> +	depends on !BR2_STATIC_LIBS
> +	depends on BR2_USE_WCHAR # std::wstring

 Again, I doubt that most of these limitations apply.

> +	select BR2_PACKAGE_HOST_CLANG
> +	help
> +	  This option will force Buildroot to use Clang as cross-compiler
> +	  instead of GCC. A GCC toolchain (internal or external) is still
> +	  needed to build with Clang.
> +
> +	  This is labeled as an experimental feature, since we are
> +	  expecting some build and runtime issues for number of packages
> +	  (bootloaders, kernel).
> +
> +	  Note: Only Glibc toolchain has been tested.
> +
>  endmenu
>  
>  comment "Security Hardening Options"
> diff --git a/package/Makefile.in b/package/Makefile.in
> index 0a7899c852..aebf4edd1b 100644
> --- a/package/Makefile.in
> +++ b/package/Makefile.in
> @@ -200,9 +200,6 @@ endif
>  # Define TARGET_xx variables for all common binutils/gcc
>  TARGET_AR       = $(TARGET_CROSS)ar
>  TARGET_AS       = $(TARGET_CROSS)as
> -TARGET_CC       = $(TARGET_CROSS)gcc
> -TARGET_CPP      = $(TARGET_CROSS)cpp
> -TARGET_CXX      = $(TARGET_CROSS)g++
>  TARGET_FC       = $(TARGET_CROSS)gfortran
>  TARGET_LD       = $(TARGET_CROSS)ld
>  TARGET_NM       = $(TARGET_CROSS)nm
> @@ -211,6 +208,16 @@ TARGET_READELF  = $(TARGET_CROSS)readelf
>  TARGET_OBJCOPY  = $(TARGET_CROSS)objcopy
>  TARGET_OBJDUMP  = $(TARGET_CROSS)objdump
>  
> +ifeq ($(BR2_USER_HOST_CLANG_AS_CROSS_COMPILER),y)
> +TARGET_CC       = $(HOST_DIR)/bin/clang
> +TARGET_CPP      = $(HOST_DIR)/bin/clang-cpp
> +TARGET_CXX      = $(HOST_DIR)/bin/clang++
> +else
> +TARGET_CC       = $(TARGET_CROSS)gcc
> +TARGET_CPP      = $(TARGET_CROSS)cpp
> +TARGET_CXX      = $(TARGET_CROSS)g++
> +endif

 This stuff is also not needed if we simply overwrite gcc, cpp, g++ and other
gcc-installed symlinks.

> +
>  ifeq ($(BR2_STRIP_strip),y)
>  STRIP_STRIP_DEBUG := --strip-debug
>  TARGET_STRIP = $(TARGET_CROSS)strip
> diff --git a/package/clang/clang.mk b/package/clang/clang.mk
> index 148df8e611..36703f5d8a 100644
> --- a/package/clang/clang.mk
> +++ b/package/clang/clang.mk
> @@ -14,6 +14,11 @@ CLANG_LICENSE_FILES = LICENSE.TXT
>  CLANG_SUPPORTS_IN_SOURCE_BUILD = NO
>  CLANG_INSTALL_STAGING = YES
>  
> +# Allow host-clang to be build as part of the toolchain
> +ifeq ($(BR2_USER_HOST_CLANG_AS_CROSS_COMPILER),y)
> +HOST_CLANG_ADD_TOOLCHAIN_DEPENDENCY = NO

 Since this is a host package, a toolchain dependency won't be added anyway.
Note how host-gcc-{initial,final} don't have it either.


 Regards,
 Arnout

> +endif
> +
>  HOST_CLANG_DEPENDENCIES = host-llvm host-libxml2
>  CLANG_DEPENDENCIES = llvm host-clang
>  
> @@ -106,7 +111,9 @@ CLANG_CONF_OPTS += -DLLVM_DYLIB_COMPONENTS=all
>  # Help host-clang to find our external toolchain, use a relative path from the clang
>  # installation directory to the external toolchain installation directory in order to
>  # not hardcode the toolchain absolute path.
> +# Install the GCC external toolchain before executing realpath command.
>  ifeq ($(BR2_TOOLCHAIN_EXTERNAL),y)
> +HOST_CLANG_DEPENDENCIES += toolchain-external
>  HOST_CLANG_CONF_OPTS += -DGCC_INSTALL_PREFIX:PATH=`realpath --relative-to=$(HOST_DIR)/bin/ $(TOOLCHAIN_EXTERNAL_INSTALL_DIR)`
>  endif
>  
> diff --git a/toolchain/toolchain/toolchain.mk b/toolchain/toolchain/toolchain.mk
> index 17fb62147e..d945e27aac 100644
> --- a/toolchain/toolchain/toolchain.mk
> +++ b/toolchain/toolchain/toolchain.mk
> @@ -10,6 +10,13 @@ else ifeq ($(BR2_TOOLCHAIN_EXTERNAL),y)
>  TOOLCHAIN_DEPENDENCIES += toolchain-external
>  endif
>  
> +# Make sure the clang cross-compiler is built before
> +# generating Buildroot.cmake file from an
> +# TOOLCHAIN_CMAKE_INSTALL_FILES hook.
> +ifeq ($(BR2_USER_HOST_CLANG_AS_CROSS_COMPILER),y)
> +TOOLCHAIN_DEPENDENCIES += host-clang
> +endif
> +
>  TOOLCHAIN_ADD_TOOLCHAIN_DEPENDENCY = NO
>  
>  # Apply a hack that Rick Felker suggested[1] to avoid conflicts between libc
> 

[Buildroot] [PATCH v2 11/12] toolchain: add a warning when Clang is used as cross-compiler

[Romain Naour]

Signed-off-by: Romain Naour <romain.naour@smile.fr>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Valentin Korenblit <valentinkorenblit@gmail.com>
---
 toolchain/Config.in | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/toolchain/Config.in b/toolchain/Config.in
index bd2c547ff1..570f029cac 100644
--- a/toolchain/Config.in
+++ b/toolchain/Config.in
@@ -37,6 +37,12 @@ config BR2_TOOLCHAIN_USES_MUSL
 	select BR2_TOOLCHAIN_HAS_UCONTEXT
 	select BR2_TOOLCHAIN_SUPPORTS_PIE if !BR2_STATIC_LIBS
 
+if BR2_USER_HOST_CLANG_AS_CROSS_COMPILER
+comment "-------------------------------------------------------"
+comment "Clang will be used as C/C++ cross-compiler !           "
+comment "-------------------------------------------------------"
+endif
+
 choice
 	prompt "Toolchain type"
 	help
-- 
2.21.0

[Buildroot] [PATCH v2 12/12] linux: don't set -Wno-attribute-alias flag when Clang is used as cross-compiler

[Romain Naour]

Clang stop the build due to -Werror and -Wunknown-warning-option:

error: unknown warning option '-Wno-attribute-alias'; did you mean '-Wattributes'? [-Werror,-Wunknown-warning-option]

Signed-off-by: Romain Naour <romain.naour@smile.fr>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Valentin Korenblit <valentinkorenblit@gmail.com>
---
 linux/linux.mk | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/linux/linux.mk b/linux/linux.mk
index d381c96d85..93d80d85e6 100644
--- a/linux/linux.mk
+++ b/linux/linux.mk
@@ -145,7 +145,8 @@ endif
 # abusing those aliases for system call entry points, in order to
 # sanitize the arguments passed from user space in registers.
 # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82435
-ifeq ($(BR2_TOOLCHAIN_GCC_AT_LEAST_8),y)
+# Clang doesn't support -Wno-attribute-alias
+ifeq ($(BR2_TOOLCHAIN_GCC_AT_LEAST_8):$(BR2_USER_HOST_CLANG_AS_CROSS_COMPILER),y:)
 LINUX_MAKE_ENV += KCFLAGS=-Wno-attribute-alias
 endif
 
-- 
2.21.0

[Buildroot] [PATCH v2 12/12] linux: don't set -Wno-attribute-alias flag when Clang is used as cross-compiler

[Matthew Weber]

Romain,

On Sat, Sep 7, 2019 at 4:40 AM Romain Naour <romain.naour@smile.fr> wrote:
>
> Clang stop the build due to -Werror and -Wunknown-warning-option:
>
> error: unknown warning option '-Wno-attribute-alias'; did you mean '-Wattributes'? [-Werror,-Wunknown-warning-option]
>
> Signed-off-by: Romain Naour <romain.naour@smile.fr>
> Cc: Matt Weber <matthew.weber@rockwellcollins.com>

Did a build time test using the qemu aarch64 configuration, selecting
the prebuilt external toolchain and enabling the Clang as
cross-compiler option.
I then booted this configuration in qemu and logged in.
# dmesg | grep clang
Linux version 4.19.16 (mlweber1 at fooobar) (clang version 8.0.1
(tags/RELEASE_801/final)) #1 SMP Mon Sep 9 09:25:19 CDT 2019
#

Tested-by: Matt Weber <matthew.weber@rockwellcollins.com>

> Cc: Valentin Korenblit <valentinkorenblit@gmail.com>
> ---
>  linux/linux.mk | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/linux/linux.mk b/linux/linux.mk
> index d381c96d85..93d80d85e6 100644
> --- a/linux/linux.mk
> +++ b/linux/linux.mk
> @@ -145,7 +145,8 @@ endif
>  # abusing those aliases for system call entry points, in order to
>  # sanitize the arguments passed from user space in registers.
>  # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82435
> -ifeq ($(BR2_TOOLCHAIN_GCC_AT_LEAST_8),y)
> +# Clang doesn't support -Wno-attribute-alias
> +ifeq ($(BR2_TOOLCHAIN_GCC_AT_LEAST_8):$(BR2_USER_HOST_CLANG_AS_CROSS_COMPILER),y:)
>  LINUX_MAKE_ENV += KCFLAGS=-Wno-attribute-alias
>  endif
>
> --
> 2.21.0
>


--

Matthew Weber | Associate Director Software Engineer | Commercial Avionics

COLLINS AEROSPACE

400 Collins Road NE, Cedar Rapids, Iowa 52498, USA

Tel: +1 319 295 7349 | FAX: +1 319 263 6099

matthew.weber at collins.com | collinsaerospace.com



CONFIDENTIALITY WARNING: This message may contain proprietary and/or
privileged information of Collins Aerospace and its affiliated
companies. If you are not the intended recipient, please 1) Do not
disclose, copy, distribute or use this message or its contents. 2)
Advise the sender by return email. 3) Delete all copies (including all
attachments) from your computer. Your cooperation is greatly
appreciated.


Any export restricted material should be shared using my
matthew.weber at corp.rockwellcollins.com address.

[Buildroot] [PATCH v2 00/12] Add the support for Clang cross-compiler

[Arnout Vandecappelle]

 Hi Romain,

 After almost a year, let's try to make some progress on this series :-)

On 07/09/2019 11:40, Romain Naour wrote:
[snip]
> Recently, I've tried to build an aarch64 Linux kernel (5.2.7) with
> Clang and it worked under Qemu [3]. I also tested for x86_64 but we need
> the upcomming llvm/clang version 9 to build the kernel [4].

 Since we waited long enough, this is now in Buildroot :-)

> This new version add the support of "asm-goto" which was the last
> missing part to be able to build the Linux kernel on x86_64 [5].
> But for theses tests, only the kernel was built with Clang.
> 
> While testing the x86_64 kernel and it's rootfs built with Clang under Qemu,
> I had a runtime issue during the userspace boot process (Busybox's init).
> While searching about the issue, I discover the lowRISC blog from Lu?s Marques
> about the same issue and tested the patch he contributed to the Busybox project
> (Thanks!).
> 
> So, this series is about to complete the integration of Clang as cross-compiler
> by using a toolchain-wrapper and fixing some build system infrastructure
> (cmake, meson) to use Clang instead of GCC.

 I started integrating the series, but then I had some fundamental problems with
the core patch itself. So I stopped and pushed my results to
https://gitlab.com/arnout/buildroot branch clang-as-cross-compiler. I put my
changes as squash patches rather than changing the original patches, so you can
easily take over from there. Note that I haven't tested my rebased and modified
branch (just a build test immediately after applying the modified patch), so
there may still be some rebase f**up there.

 I'll put my feedback in the individual patches.

 Regards,
 Arnout

> 
> Add this new experimental option into "Advanced" menu since we are expecting
> some build and runtime issues for number of packages (bootloaders, kernel).
> 
> For now, Clang cross-compiler can only be use as internal toolchain,
> so it is build from the source which take a long time...
[snip]

[Buildroot] [PATCH v2 00/12] Add the support for Clang cross-compiler

[Romain Naour]

Hi Arnout,

Le 29/08/2020 ? 20:53, Arnout Vandecappelle a ?crit?:
>  Hi Romain,
> 
>  After almost a year, let's try to make some progress on this series :-)
> 
> On 07/09/2019 11:40, Romain Naour wrote:
> [snip]
>> Recently, I've tried to build an aarch64 Linux kernel (5.2.7) with
>> Clang and it worked under Qemu [3]. I also tested for x86_64 but we need
>> the upcomming llvm/clang version 9 to build the kernel [4].
> 
>  Since we waited long enough, this is now in Buildroot :-)

We are in late about llvm version, the version 11 should be released anytime soon.

> 
>> This new version add the support of "asm-goto" which was the last
>> missing part to be able to build the Linux kernel on x86_64 [5].
>> But for theses tests, only the kernel was built with Clang.
>>
>> While testing the x86_64 kernel and it's rootfs built with Clang under Qemu,
>> I had a runtime issue during the userspace boot process (Busybox's init).
>> While searching about the issue, I discover the lowRISC blog from Lu?s Marques
>> about the same issue and tested the patch he contributed to the Busybox project
>> (Thanks!).
>>
>> So, this series is about to complete the integration of Clang as cross-compiler
>> by using a toolchain-wrapper and fixing some build system infrastructure
>> (cmake, meson) to use Clang instead of GCC.
> 
>  I started integrating the series, but then I had some fundamental problems with
> the core patch itself. So I stopped and pushed my results to
> https://gitlab.com/arnout/buildroot branch clang-as-cross-compiler. I put my
> changes as squash patches rather than changing the original patches, so you can
> easily take over from there. Note that I haven't tested my rebased and modified
> branch (just a build test immediately after applying the modified patch), so
> there may still be some rebase f**up there.
> 
>  I'll put my feedback in the individual patches.

Thanks!

I'm not sure how many free time I will able to devote to this series.
I recently did a test with llvm/clang 10 for risv64 [1] but the series needs
some work to be upstreamable...

I'd like to be able to work on this series as a full day job :)

[1] https://asciinema.org/a/DDspJVktlVl1Rh97dwLgtYcRY

Best regards,
Romain

> 
>  Regards,
>  Arnout
> 
>>
>> Add this new experimental option into "Advanced" menu since we are expecting
>> some build and runtime issues for number of packages (bootloaders, kernel).
>>
>> For now, Clang cross-compiler can only be use as internal toolchain,
>> so it is build from the source which take a long time...
> [snip]
>