Subject: Bug#1037185: bpftrace: Fix FTBFS on armhf

From: Danilo Egea Gondolfo <[email-masked]>
Date: Wed, 7 Jun 2023 11:07:52 +0100

Package: bpftrace
Version: 0.17.0-2
Severity: normal
Tags: patch
User: [email-masked]
Usertags: origin-ubuntu mantic ubuntu-patch

Dear Maintainer,

* What led up to the situation?

The build is failing on armhf because cmake is not detecting the 
architecture correctly as we cross compile on arm64.

Also, after fixing the cmake part, the build will fail in src/triggers.h 
due to the attribute used when it build on arm 32-bit. It might be a bug 
on gcc but I'm not sure (clang++ doesn't throw the same error).

* What exactly did you do (or not do) that was effective (or ineffective)?

Patched debian/rules

* What was the outcome of this action?

The build is working on armhf and bpftrace works as expected.

*** /tmp/tmpyvgtuueq/bug_body

In Ubuntu, the attached patch was applied to achieve the following:

* Fix FTBFS on armhf.
As we cross compile bpftrace for armhf on arm64, cmake is not detecting
the architecture correctly.
It will also set the ISA explicitly to ARM to fix a problem in
src/triggers.h caused by the target("arm") attribute where the g++
compiler fails with "invalid conversion from ‘void (*)()’ to ‘void (*)()’"

Thanks for considering the patch.

*** /tmp/tmpyvgtuueq/bpftrace_0.17.0-2ubuntu1.debdiff
diff -Nru bpftrace-0.17.0/debian/rules bpftrace-0.17.0/debian/rules
--- bpftrace-0.17.0/debian/rules 2023-04-10 11:59:06.000000000 +0100
+++ bpftrace-0.17.0/debian/rules 2023-06-06 18:54:52.000000000 +0100
@@ -1,10 +1,20 @@
#!/usr/bin/make -f

+ifeq ($(DEB_HOST_ARCH), armhf)
+ # When cross compiling on arm64 for armhf, cmake will detect the 
architecture as armv8l.
+ # The CMAKE_SYSTEM_NAME appears to be required so cmake will actually 
use CMAKE_SYSTEM_PROCESSOR
+ # -marm is used so the build will not fail due to the 
__attribute__((target("arm")) in src/triggers.h
+ # when compiling with -mthumb. The g++ compiler will error out with:
+ # "invalid conversion from ‘void (*)()’ to ‘void (*)()’"
+ # See https://github.com/iovisor/bpftrace/commit/56106a650a8
+ ARMHF_FLAGS=-DCMAKE_SYSTEM_PROCESSOR:STRING="armv7-a" 
-DCMAKE_SYSTEM_NAME:STRING=Linux -DCMAKE_CXX_FLAGS:STRING=-marm
+endif
+
%:
dh $@

override_dh_auto_configure:
- dh_auto_configure -- -DBUILD_TESTING:BOOL=OFF -DUSE_SYSTEM_BPF_BCC=1
+ dh_auto_configure -- ${ARMHF_FLAGS} -DBUILD_TESTING:BOOL=OFF 
-DUSE_SYSTEM_BPF_BCC=1

STRIP_CMD=strip --keep-symbol=BEGIN_trigger --keep-symbol=END_trigger 
--remove-section=.comment --remove-section=.note
override_dh_strip:

-- System Information:
Debian Release: bookworm/sid
APT prefers mantic
APT policy: (500, 'mantic'), (100, 'mantic-proposed')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.2.0-21-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

---

From: Vincent Bernat <[email-masked]>
Date: Wed, 7 Jun 2023 23:09:14 +0200

> on gcc but I'm not sure (clang++ doesn't throw the same error).

Shouldn't all this be fixed upstream?

---

From: Danilo Egea Gondolfo <[email-masked]>
Date: Tue, 13 Jun 2023 09:25:45 +0100

On 07/06/2023 22:09, Vincent Bernat wrote:

>> Also, after fixing the cmake part, the build will fail in 
>> src/triggers.h due to the attribute used when it build on arm 32-bit. 
>> It might be a bug on gcc but I'm not sure (clang++ doesn't throw the 
>> same error).
>

Hi,

I've started a discussion here https://github.com/iovisor/bpftrace/pull/2360

It appears to be a bug in GCC. One of the developers replied with a nice 
explanation on why this code is required and suggested that building the 
entire package using the ARM ISA could be a good solution.

---

From: Danilo Egea Gondolfo <[email-masked]>
Date: Wed, 12 Jul 2023 18:40:09 +0100

> Shouldn't all this be fixed upstream?
Both problems were fixed upstream 
https://github.com/iovisor/bpftrace/issues/2654