Skip to contentSkip to conversation

llvm: fix build of host-llvm

PATCH New Fabrice Fontaine 4 participants 16 messages Nov 3, 2018

lore
Share & tools
lore

Fabrice Fontaine

author
#0 lore raw

PATCH 1/4 llvm: fix build of host-llvm

If BR2_PACKAGE_LLVM_TARGET_ARCH is empty because llvm is not supported on target, build of the host-llvm will fail on "Unknown architecture".

This is an issue because host-llvm (and host-clang) can be needed on host. For example the libv4l package uses clang to build BPF (in-kernel bytecode machine) files.

To fix this, add a new "host" default value to
BR2_PACKAGE_LLVM_TARGET_ARCH

Signed-off-by Fabrice Fontaine <[email protected]>
---
 package/llvm/Config.in | 1 +
 1 file changed, 1 insertion(+)
package/llvm/Config.in +1 -0
index 83e94660eb..0e111f1b76 100644
@@ -10,6 +10,7 @@ config BR2_PACKAGE_LLVM_TARGET_ARCH
 	default "AArch64" if BR2_aarch64
 	default "ARM" if BR2_arm || BR2_armeb
 	default "X86" if BR2_i386 || BR2_x86_64
+	default "host"
 
 config BR2_PACKAGE_LLVM
 	bool "llvm"
Signature · 1 line
2.17.1
author
#1 lore raw

PATCH 2/4 llvm: enable bpf

BPF (in-kernel bytecode machine) is needed by libv4l

Signed-off-by Fabrice Fontaine <[email protected]>
---
 package/llvm/llvm.mk | 3 +++
 1 file changed, 3 insertions(+)
package/llvm/llvm.mk +3 -0
index 1f9bd447f5..dae5d3f16d 100644
@@ -54,6 +54,9 @@ ifeq ($(BR2_PACKAGE_LLVM_AMDGPU),y)
 LLVM_TARGETS_TO_BUILD += AMDGPU
 endif
 
+# Build BPF (in-kernel bytecode machine)
+LLVM_TARGETS_TO_BUILD += BPF
+
 # Use native llvm-tblgen from host-llvm (needed for cross-compilation)
 LLVM_CONF_OPTS += -DLLVM_TABLEGEN=$(HOST_DIR)/bin/llvm-tblgen
Signature · 1 line
2.17.1
#2 lore raw

PATCH 2/4 llvm: enable bpf

Hello,

Quoted 12 lines · Fabrice Fontaine

BPF (in-kernel bytecode machine) is needed by libv4l

Signed-off-by Fabrice Fontaine <[email protected]>
---
 package/llvm/llvm.mk | 3 +++
 1 file changed, 3 insertions(+)
package/llvm/llvm.mk +0 -0
index 1f9bd447f5..dae5d3f16d 100644

package/llvm/llvm.mk ifeq ($(BR2_PACKAGE_LLVM_AMDGPU),y) · line 58

Quoted 5 lines
package/llvm/llvm.mk +2 -0
@@ -54,6 +54,9 @@ ifeq ($(BR2_PACKAGE_LLVM_AMDGPU),y)
 LLVM_TARGETS_TO_BUILD += AMDGPU
 endif
 
+# Build BPF (in-kernel bytecode machine)
+LLVM_TARGETS_TO_BUILD += BPF

Perhaps we should make this optional ? Or maybe the build time difference is not that significant ?

Best regards,

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
author
#3 lore raw

PATCH 2/4 llvm: enable bpf

Dear Thomas,
Le sam. 3 nov. 2018 ? 14:14, Thomas Petazzoni
<[email protected]> a ?crit :

Quoted 19 lines

Hello,

Quoted 15 lines · Fabrice Fontaine

BPF (in-kernel bytecode machine) is needed by libv4l

Signed-off-by Fabrice Fontaine <[email protected]>
---
 package/llvm/llvm.mk | 3 +++
 1 file changed, 3 insertions(+)
package/llvm/llvm.mk +0 -0
index 1f9bd447f5..dae5d3f16d 100644
@@ -54,6 +54,9 @@ ifeq ($(BR2_PACKAGE_LLVM_AMDGPU),y)
 LLVM_TARGETS_TO_BUILD += AMDGPU
 endif
Quoted 5 lines

package/llvm/llvm.mk ifeq ($(BR2_PACKAGE_LLVM_AMDGPU),y) · line 58

Quoted 2 lines
package/llvm/llvm.mk +2 -0
+# Build BPF (in-kernel bytecode machine)
+LLVM_TARGETS_TO_BUILD += BPF

Perhaps we should make this optional ? Or maybe the build time difference is not that significant ?

llvm and clang are already taking a long time to build on my "old" machine, I didn't notice a significant difference with or without BPF but I didn't measure it.

Quoted 8 lines

Best regards,

Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Best Regards,

Fabrice

#4 lore raw

PATCH 2/4 llvm: enable bpf

Fabrice, Thomas,

Quoted 21 lines

Dear Thomas,
Le sam. 3 nov. 2018 ? 14:14, Thomas Petazzoni
<[email protected]> a ?crit :

Quoted 18 lines

Hello,

Quoted 15 lines · Fabrice Fontaine

BPF (in-kernel bytecode machine) is needed by libv4l

Signed-off-by Fabrice Fontaine <[email protected]>
---
  package/llvm/llvm.mk | 3 +++
  1 file changed, 3 insertions(+)
package/llvm/llvm.mk +0 -0
index 1f9bd447f5..dae5d3f16d 100644
@@ -54,6 +54,9 @@ ifeq ($(BR2_PACKAGE_LLVM_AMDGPU),y)
  LLVM_TARGETS_TO_BUILD += AMDGPU
  endif
Quoted 7 lines
Quoted 4 lines

package/llvm/llvm.mk ifeq ($(BR2_PACKAGE_LLVM_AMDGPU),y) · line 58

Quoted 2 lines
package/llvm/llvm.mk +2 -0
+# Build BPF (in-kernel bytecode machine)
+LLVM_TARGETS_TO_BUILD += BPF

Perhaps we should make this optional ? Or maybe the build time difference is not that significant ?

llvm and clang are already taking a long time to build on my "old" machine, I didn't notice a significant difference with or without BPF but I didn't measure it.

I think we should add a new option just like we did with AMDGPU backend as we said we were only going to build backend for target archictecture by default.

Quoted 10 lines
Quoted 7 lines

Best regards,

Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Best Regards,

Fabrice

Best regards,

Valentin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20181103/bf3d35b5/attachment.html>

author
#5 lore raw

PATCH 2/4 llvm: enable bpf

Dear Valentin,
Le sam. 3 nov. 2018 ? 15:24, Valentin Korenblit
<[email protected]> a ?crit :

Quoted 32 lines

Fabrice, Thomas,

Dear Thomas,
Le sam. 3 nov. 2018 ? 14:14, Thomas Petazzoni
<[email protected]> a ?crit :

Hello,

On Sat, 3 Nov 2018 13:27:56 +0100, Fabrice Fontaine wrote:

BPF (in-kernel bytecode machine) is needed by libv4l

Signed-off-by Fabrice Fontaine <[email protected]>
---
 package/llvm/llvm.mk | 3 +++
 1 file changed, 3 insertions(+)
package/llvm/llvm.mk +2 -0
index 1f9bd447f5..dae5d3f16d 100644
@@ -54,6 +54,9 @@ ifeq ($(BR2_PACKAGE_LLVM_AMDGPU),y)
 LLVM_TARGETS_TO_BUILD += AMDGPU
 endif
 
+# Build BPF (in-kernel bytecode machine)
+LLVM_TARGETS_TO_BUILD += BPF

Perhaps we should make this optional ? Or maybe the build time difference is not that significant ?

Quoted 7 lines

llvm and clang are already taking a long time to build on my "old" machine, I didn't notice a significant difference with or without BPF but I didn't measure it.

I think we should add a new option just like we did with AMDGPU backend as we said we were only going to build backend for target archictecture by default.

I would like some advice to add this option, this BPF option should be selectable even if BR2_PACKAGE_LLVM is not set as llvm is not needed on the target.

So should I put some kind of hidden option like:
config BR2_PACKAGE_HOST_LLVM_TARGET_BPF
bool

and select it in libv4l/Config.in?

Quoted 9 lines

Best regards,

Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Quoted 7 lines

Best Regards,

Fabrice

Best regards,

Valentin

Best Regards,

Fabrice

author
#6 lore raw

PATCH 3/4 libv4l: add elfutils optional dependency

In reply to Fabrice Fontaine

Bump to version 1.61.1 added an optional dependency to elfutils:
https://git.linuxtv.org/v4l-utils.git/commit/?id=d6025b0e8c7f57b0f9390f987acc5eed57360d80

host-clang is also needed to build PBF protocols, see:
https://git.linuxtv.org/v4l-utils.git/commit/?id=91b37c0d9cb71fc2d5f78cc96aa2ef9f3bba145b

Signed-off-by Fabrice Fontaine <[email protected]>
---
 package/libv4l/libv4l.mk | 6 ++++++
 1 file changed, 6 insertions(+)
package/libv4l/libv4l.mk +6 -0
index 4e82dea6ad..7be41f8fef 100644
@@ -55,6 +55,12 @@ endif
 ifeq ($(BR2_PACKAGE_LIBV4L_UTILS),y)
 LIBV4L_CONF_OPTS += --enable-v4l-utils
 LIBV4L_DEPENDENCIES += $(TARGET_NLS_DEPENDENCIES)
+
+ifeq ($(BR2_PACKAGE_ELFUTILS),y)
+# host-clang is needed to build BPF protocols
+LIBV4L_DEPENDENCIES += elfutils host-clang
+endif
+
 ifeq ($(BR2_PACKAGE_QT5BASE)$(BR2_PACKAGE_QT5BASE_GUI)$(BR2_PACKAGE_QT5BASE_WIDGETS),yyy)
 LIBV4L_CONF_OPTS += --enable-qv4l2
 LIBV4L_DEPENDENCIES += qt5base
Signature · 1 line
2.17.1
#7 lore raw

PATCH 3/4 libv4l: add elfutils optional dependency

Hello,

Quoted 4 lines · Fabrice Fontaine

Bump to version 1.61.1 added an optional dependency to elfutils:
https://git.linuxtv.org/v4l-utils.git/commit/?id=d6025b0e8c7f57b0f9390f987acc5eed57360d80

host-clang is also needed to build PBF protocols, see:

PBF -> BPF

Quoted 1 line

https://git.linuxtv.org/v4l-utils.git/commit/?id=91b37c0d9cb71fc2d5f78cc96aa2ef9f3bba145b

I'm not sure to understand: there are two separate commits upstream, one that adds the elfutils dependency, one that adds the clang dependency. Are they both needed to have BPF protocols ? If so, why were those two dependencies introduced in separate commits upstream ?

package/libv4l/libv4l.mk endif · line 62

Quoted 4 lines
package/libv4l/libv4l.mk +4 -0
+ifeq ($(BR2_PACKAGE_ELFUTILS),y)
+# host-clang is needed to build BPF protocols
+LIBV4L_DEPENDENCIES += elfutils host-clang
+endif

I think an explicit sub-option would make sense in this case, because it's not trivial at all to know that you need elfutils. So I would prefer to have

config BR2_PACKAGE_LIBV4L_KEYTABLE_BPF_PROTOCOLS
bool "keytable BPF protocols"
select BR2_PACKAGE_ELFUTILS
depends on BR2_USE_WCHAR # elfutils
depends on !BR2_STATIC_LIBS # elfutils
depends on BR2_TOOLCHAIN_USES_UCLIBC || BR2_TOOLCHAIN_USES_GLIBC # elfutils

Thanks,

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
author
#8 lore raw

PATCH 3/4 libv4l: add elfutils optional dependency

Dear Thomas,
Le sam. 3 nov. 2018 ? 14:18, Thomas Petazzoni
<[email protected]> a ?crit :

Quoted 9 lines

Hello,

Quoted 4 lines · Fabrice Fontaine

Bump to version 1.61.1 added an optional dependency to elfutils:
https://git.linuxtv.org/v4l-utils.git/commit/?id=d6025b0e8c7f57b0f9390f987acc5eed57360d80

host-clang is also needed to build PBF protocols, see:

Quoted 8 lines

PBF -> BPF

Quoted 1 line

https://git.linuxtv.org/v4l-utils.git/commit/?id=91b37c0d9cb71fc2d5f78cc96aa2ef9f3bba145b

I'm not sure to understand: there are two separate commits upstream, one that adds the elfutils dependency, one that adds the clang dependency. Are they both needed to have BPF protocols ? If so, why were those two dependencies introduced in separate commits upstream ?

Yes, BPF protocols are enabled only if elfutils is available:

AM_CONDITIONAL([HAVE_LIBELF], [test x$libelf_pkgconfig = xyes]) if test "x$libelf_pkgconfig" = "xyes"; then AC_CHECK_PROG([CLANG], clang, clang) AC_DEFINE([HAVE_LIBELF], [1], [libelf library is present]) else
AC_MSG_WARN(libelf library not available)
fi

Quoted 10 lines

package/libv4l/libv4l.mk endif · line 62

Quoted 5 lines
package/libv4l/libv4l.mk +4 -0
+ifeq ($(BR2_PACKAGE_ELFUTILS),y)
+# host-clang is needed to build BPF protocols
+LIBV4L_DEPENDENCIES += elfutils host-clang
+endif

I think an explicit sub-option would make sense in this case, because it's not trivial at all to know that you need elfutils. So I would prefer to have

Quoted 6 lines

config BR2_PACKAGE_LIBV4L_KEYTABLE_BPF_PROTOCOLS
bool "keytable BPF protocols"
select BR2_PACKAGE_ELFUTILS
depends on BR2_USE_WCHAR # elfutils
depends on !BR2_STATIC_LIBS # elfutils
depends on BR2_TOOLCHAIN_USES_UCLIBC || BR2_TOOLCHAIN_USES_GLIBC # elfutils

OK, I will update the patch to add this option.

Quoted 8 lines

Thanks,

Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Best Regards,

Fabrice

author
#9 lore raw

PATCH 4/4 scripts/check-bin-arch: fix failure with bpf

In reply to Fabrice Fontaine

Do not return an error if architecture is "Linux BPF" (in-kernel bytecode machine)

Fixes:
- http://autobuild.buildroot.org/results/c18fb7f1ac81496db9c3a4e91ea028a26ca600b0

Signed-off-by Fabrice Fontaine <[email protected]>
---
 support/scripts/check-bin-arch | 5 +++++
 1 file changed, 5 insertions(+)
support/scripts/check-bin-arch +5 -0
index 7f97696735..a0de7a6ac4 100755
@@ -74,6 +74,11 @@ while read f; do
 		continue
 	fi
 
+	# If architecture is Linux BPF (in-kernel bytecode machine), continue
+	if test "${arch}" = "Linux BPF" ; then
+		continue
+	fi
+
 	# Architecture is correct
 	if test "${arch}" = "${arch_name}" ; then
 		continue
Signature · 1 line
2.17.1
#10 lore raw

PATCH 4/4 scripts/check-bin-arch: fix failure with bpf

Hello,

Quoted 16 lines · Fabrice Fontaine

Do not return an error if architecture is "Linux BPF" (in-kernel bytecode machine)

Fixes:
- http://autobuild.buildroot.org/results/c18fb7f1ac81496db9c3a4e91ea028a26ca600b0

Signed-off-by Fabrice Fontaine <[email protected]>
---
 support/scripts/check-bin-arch | 5 +++++
 1 file changed, 5 insertions(+)
support/scripts/check-bin-arch +0 -0
index 7f97696735..a0de7a6ac4 100755

support/scripts/check-bin-arch while read f; do · line 80

Quoted 7 lines
support/scripts/check-bin-arch +4 -0
@@ -74,6 +74,11 @@ while read f; do
 		continue
 	fi
 
+	# If architecture is Linux BPF (in-kernel bytecode machine), continue
+	if test "${arch}" = "Linux BPF" ; then
+		continue
+	fi

In the build failure
http://autobuild.buildroot.org/results/c18fb7f1ac81496db9c3a4e91ea028a26ca600b0/build-end.log
that you point, the architecture is reported as "None", not as "Linux BPF". Am I misunderstanding something here ?

As a first step, could we explicitly disable building BPF protocols, before we merge the necessary LLVM/V4L logic to build these properly ?

Thanks,

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
author
#11 lore raw

PATCH 4/4 scripts/check-bin-arch: fix failure with bpf

Dear Thomas,
Le sam. 3 nov. 2018 ? 14:20, Thomas Petazzoni
<[email protected]> a ?crit :

Quoted 23 lines

Hello,

Quoted 19 lines · Fabrice Fontaine

Do not return an error if architecture is "Linux BPF" (in-kernel bytecode machine)

Fixes:
- http://autobuild.buildroot.org/results/c18fb7f1ac81496db9c3a4e91ea028a26ca600b0

Signed-off-by Fabrice Fontaine <[email protected]>
---
 support/scripts/check-bin-arch | 5 +++++
 1 file changed, 5 insertions(+)
support/scripts/check-bin-arch +0 -0
index 7f97696735..a0de7a6ac4 100755
@@ -74,6 +74,11 @@ while read f; do
              continue
      fi
Quoted 9 lines

support/scripts/check-bin-arch while read f; do · line 80

Quoted 4 lines
support/scripts/check-bin-arch +4 -0
+     # If architecture is Linux BPF (in-kernel bytecode machine), continue
+     if test "${arch}" = "Linux BPF" ; then
+             continue
+     fi

In the build failure
http://autobuild.buildroot.org/results/c18fb7f1ac81496db9c3a4e91ea028a26ca600b0/build-end.log
that you point, the architecture is reported as "None", not as "Linux BPF". Am I misunderstanding something here ?

I wasn't able to reproduce this "None" architecture issue. But I think it was "None" because the llvm/clang found on Peter's machine was very old (3.8):
clang -idirafter /usr/local/include -idirafter /usr/lib/llvm-3.8/bin/../lib/clang/3.8.1/include -idirafter /usr/include/x86_64-linux-gnu -idirafter /usr/include -I../../../include -target bpf -O2 -c grundig.c

With my patch's serie, I'm building a host-clang in version 7.0 that supports BPF and in this case the architecture is correctly set to "Linux BPF".
I tested with a clang in version 6.0 installed from Ubuntu 18.04 repositories on my host machine and it was also "Linux BPF".

Quoted 3 lines

As a first step, could we explicitly disable building BPF protocols, before we merge the necessary LLVM/V4L logic to build these properly ?

Ok, I will do that.

Quoted 8 lines

Thanks,

Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Best Regards,

Fabrice

#12 lore raw

PATCH 4/4 scripts/check-bin-arch: fix failure with bpf

Hello,

Quoted 8 lines · Fabrice Fontaine

I wasn't able to reproduce this "None" architecture issue. But I think it was "None" because the llvm/clang found on Peter's machine was very old (3.8):
clang -idirafter /usr/local/include -idirafter /usr/lib/llvm-3.8/bin/../lib/clang/3.8.1/include -idirafter /usr/include/x86_64-linux-gnu -idirafter /usr/include -I../../../include -target bpf -O2 -c grundig.c

Quoted 5 lines

With my patch's serie, I'm building a host-clang in version 7.0 that supports BPF and in this case the architecture is correctly set to "Linux BPF".
I tested with a clang in version 6.0 installed from Ubuntu 18.04 repositories on my host machine and it was also "Linux BPF".

OK, but then you're not fixing the problem on Peter's machine: with your patch series, if he doesn't enable BR2_PACKAGE_ELFUTILS, libv4l configure script will still detect the system-wide clang/llvm installed, which will produce those bogus "None" binaries.

Which is why there is a need to explicitly disable building the BPF protocol support, except if we know that Buildroot is providing all the necessary dependencies.

Thanks!

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
#13 lore raw

PATCH 1/4 llvm: fix build of host-llvm

In reply to Fabrice Fontaine

Hi Fabrice,

Le 03/11/2018 ? 13:27, Fabrice Fontaine a ?crit?:

Quoted 20 lines

If BR2_PACKAGE_LLVM_TARGET_ARCH is empty because llvm is not supported on target, build of the host-llvm will fail on "Unknown architecture".

This is an issue because host-llvm (and host-clang) can be needed on host. For example the libv4l package uses clang to build BPF (in-kernel bytecode machine) files.

To fix this, add a new "host" default value to
BR2_PACKAGE_LLVM_TARGET_ARCH

Signed-off-by Fabrice Fontaine <[email protected]>
---
 package/llvm/Config.in | 1 +
 1 file changed, 1 insertion(+)
package/llvm/Config.in +0 -0
index 83e94660eb..0e111f1b76 100644

package/llvm/Config.in config BR2_PACKAGE_LLVM_TARGET_ARCH · line 13

Quoted 4 lines
package/llvm/Config.in +1 -0
@@ -10,6 +10,7 @@ config BR2_PACKAGE_LLVM_TARGET_ARCH
 	default "AArch64" if BR2_aarch64
 	default "ARM" if BR2_arm || BR2_armeb
 	default "X86" if BR2_i386 || BR2_x86_64
+	default "host"

I'm not sure this is the correct thing to do since BR2_PACKAGE_LLVM_TARGET_ARCH will be used for the target variant.

"host" stand for "automatic detection"

Maybe you want to add "X86" along with LLVM_TARGETS_TO_BUILD for host-llvm ?

Something like:

HOST_LLVM_TARGETS_TO_BUILD = $(LLVM_TARGETS_TO_BUILD) X86

HOST_LLVM_CONF_OPTS += -DLLVM_TARGETS_TO_BUILD="$(subst $(space),;,$(HOST_LLVM_TARGETS_TO_BUILD))"

Also your host must be an x86 or x86_64.

Best regards,
Romain

Quoted 4 lines
package/llvm/Config.in +0 -0
 config BR2_PACKAGE_LLVM
 	bool "llvm"
#14 lore raw

PATCH 1/4 llvm: fix build of host-llvm

Hello,

Quoted 9 lines · Romain Naour

package/llvm/Config.in config BR2_PACKAGE_LLVM_TARGET_ARCH · line 13

Quoted 5 lines
package/llvm/Config.in +1 -0
@@ -10,6 +10,7 @@ config BR2_PACKAGE_LLVM_TARGET_ARCH
 	default "AArch64" if BR2_aarch64
 	default "ARM" if BR2_arm || BR2_armeb
 	default "X86" if BR2_i386 || BR2_x86_64
+	default "host"

I'm not sure this is the correct thing to do since BR2_PACKAGE_LLVM_TARGET_ARCH will be used for the target variant.

Quoted 7 lines

"host" stand for "automatic detection"

Maybe you want to add "X86" along with LLVM_TARGETS_TO_BUILD for host-llvm ?

Something like:

HOST_LLVM_TARGETS_TO_BUILD = $(LLVM_TARGETS_TO_BUILD) X86

For the host, it makes sense to use "automatic detection", so what about:

HOST_LLVM_TARGETS_TO_BUILD = $(LLVM_TARGETS_TO_BUILD) host

i.e, have support for the target architecture, but also the architecture ?

However, presumably, LLVM may not have support for all host architectures, so this calls for a BR2_PACKAGE_HOST_LLVM_ARCH_SUPPORTS ?

Best regards,

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
author
#15 lore raw

PATCH 1/4 llvm: fix build of host-llvm

Dear Thomas,
Le sam. 3 nov. 2018 ? 15:36, Thomas Petazzoni
<[email protected]> a ?crit :

Quoted 22 lines

Hello,

Quoted 9 lines · Romain Naour

package/llvm/Config.in config BR2_PACKAGE_LLVM_TARGET_ARCH · line 13

Quoted 5 lines
package/llvm/Config.in +1 -0
@@ -10,6 +10,7 @@ config BR2_PACKAGE_LLVM_TARGET_ARCH
    default "AArch64" if BR2_aarch64
    default "ARM" if BR2_arm || BR2_armeb
    default "X86" if BR2_i386 || BR2_x86_64
+   default "host"

I'm not sure this is the correct thing to do since BR2_PACKAGE_LLVM_TARGET_ARCH will be used for the target variant.

Quoted 7 lines

"host" stand for "automatic detection"

Maybe you want to add "X86" along with LLVM_TARGETS_TO_BUILD for host-llvm ?

Something like:

HOST_LLVM_TARGETS_TO_BUILD = $(LLVM_TARGETS_TO_BUILD) X86

Quoted 7 lines

For the host, it makes sense to use "automatic detection", so what about:

HOST_LLVM_TARGETS_TO_BUILD = $(LLVM_TARGETS_TO_BUILD) host

i.e, have support for the target architecture, but also the architecture ?

The issue is not with LLVM_TARGETS_TO_BUILD but with LLVM_TARGET_ARCH. LLVM_TARGET_ARCH can't be empty and it can only contain a single value. That why I put a new default value of "host" for BR2_PACKAGE_LLVM_TARGET_ARCH if no other values are provided.

Quoted 3 lines

However, presumably, LLVM may not have support for all host architectures, so this calls for a BR2_PACKAGE_HOST_LLVM_ARCH_SUPPORTS ?

Indeed, that would make sense. From what I can read here:
https://llvm.org/docs/GettingStarted.html#hardware, it seems that llvm should build on x86, ARM, powerpc.
I would suggest to add this new variable:
config BR2_PACKAGE_HOST_LLVM_ARCH_SUPPORTS
bool
default y if BR2_HOSTARCH = "x86_64"
default y if BR2_HOSTARCH = "x86"
default y if BR2_HOSTARCH = "powerpc"
default y if BR2_HOSTARCH = "arm"
default y if BR2_HOSTARCH = "aarch64"

and do:

config BR2_PACKAGE_LLVM_TARGET_ARCH
string
default "AArch64" if BR2_aarch64
default "ARM" if BR2_arm || BR2_armeb default "X86" if BR2_i386 || BR2_x86_64 default "host" if BR2_PACKAGE_HOST_LLVM_ARCH_SUPPORTS

Does it make sense?

Quoted 8 lines

Best regards,

Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Best Regards,

Fabrice