The 0003 patch that links the data_source test carrier binary without
the host runtime also adds -fno-stack-protector to the object compile
line, needed because host gcc toolchains default to
-fstack-protector-strong and the -nostdlib link then fails with:
data_source.c:212: undefined reference to `__stack_chk_fail'
However patch 0001 (DEBUG_PREFIX_MAP) runs first in SRC_URI and rewrites
the same compile line to insert ${DEBUG_PREFIX_MAP_LIST}, so 0003's
first hunk no longer matched the tree and the -fno-stack-protector flag
was silently dropped from the object compile (it only landed on the
link line). Rebase 0003's first hunk onto the post-0001 context so the
flag is applied where it is needed.
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
The build host HOME directory check recently added to OE-Core's
buildpaths QA test flags the ptest gtest binary:
WARNING: bpftrace-0.25.1-r0 do_package_qa: QA Issue: File
/usr/lib/bpftrace/ptest/tests/bpftrace_test in package bpftrace-ptest
contains a reference to the build host HOME directory. [buildpaths]
WARNING: bpftrace-0.25.1-r0 do_package_qa: QA Issue: File
/usr/lib/bpftrace/ptest/tests/.debug/bpftrace_test in package
bpftrace-dbg contains a reference to the build host HOME directory.
[buildpaths]
cmake/BuildBPF.cmake links the intermediate DWARF carrier binary
data_source_exe with the plain build host gcc, which bakes the host
dynamic loader's absolute path into the PT_INTERP segment. With a
distro gcc that is an innocuous /lib64/ld-linux-x86-64.so.2, but when
the host toolchain is a buildtools-extended/SDK gcc installed under
the build user's home directory (as on the autobuilder workers), it
is a $HOME-prefixed path like
/srv/pokybuild/.../buildtools/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2
The executable is then embedded byte-for-byte into bpftrace_test via
embed()/xxd (tests/data/CMakeLists.txt), so the path ends up in the
test binary's .rodata, triggering the bpftrace-ptest warning. And
because cmake/Embed.tmpl declares the embedded blob as a constexpr
array, gcc additionally copies its contents into .debug_info as
DW_AT_const_value, which is how the same string survives
objcopy --only-keep-debug into the split debug file, triggering the
bpftrace-dbg warning. This is the same embedding mechanism that
previously leaked TMPDIR paths, fixed for the compile step by the
DEBUG_PREFIX_MAP patch; the link step was still leaking.
The tests only write this binary to a temp file and use it as a
uprobe target (tests/dwarf_common.h), parsing its DWARF and symbols;
it is never executed. So link it with -nostdlib -no-pie -Wl,--entry=0:
no interpreter, no host crt objects, no dynamic segment, and thus
nothing host-specific in the embedded blob. Function symbols, DWARF
type information and the pahole -J BTF encoding step are unaffected,
and the field_analyser_dwarf ptests still pass.
Because the object is now linked -nostdlib it must not reference the
libc stack-protector runtime. Host gcc toolchains that default to
-fstack-protector-strong (e.g. Debian/Ubuntu and the Yocto
autobuilder workers) otherwise leave an undefined reference and the
link fails:
ld: data_source.o: in function `main':
data_source.c:212: undefined reference to `__stack_chk_fail'
collect2: error: ld returned 1 exit status
Compile the object and link the binary with -fno-stack-protector; the
canary is irrelevant to a DWARF/BTF carrier that is never run.
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
With the current version, I had the QA issues below:
WARNING: bpftrace-0.25.1-r0 do_package_qa: QA Issue:
File /usr/lib/bpftrace/ptest/tests/.debug/bpftrace_test in package bpftrace-dbg contains reference to TMPDIR [buildpaths]
WARNING: bpftrace-0.25.1-r0 do_package_qa: QA Issue:
File /usr/lib/bpftrace/ptest/tests/bpftrace_test in package bpftrace-ptest contains reference to TMPDIR [buildpaths]
A bit of find + grep + strings show that this originally comes from:
field_analyser.cpp.o: [my tmpdir...]/bpftrace/0.25.1/build/tests/data
field_analyser.cpp.o: [my tmpdir...]/bpftrace/0.25.1/sources/bpftrace-0.25.1/tests/data/data_source.c
field_analyser.cpp.o: [my tmpdir...]/bpftrace/0.25.1/sources/bpftrace-0.25.1/tests/data
The .rodata section is infected with these, and after some more digging,
the paths come from debug symbols (i.e., .debug_line_str) in
data_source.o:
build/tests/data/data_source.o: /src/update-2026.01/build/tmp/work/riscv64.../bpftrace/0.25.1/build/tests/data
build/tests/data/data_source.o: /src/update-2026.01/build/tmp/work/riscv64.../bpftrace/0.25.1/sources/bpftrace-0.25.1/tests/data/data_source.c
build/tests/data/data_source.o: /src/update-2026.01/build/tmp/work/riscv64.../bpftrace/0.25.1/build/tests/data
build/tests/data/data_source.o: /src/update-2026.01/build/tmp/work/riscv64.../bpftrace/0.25.1/sources/bpftrace-0.25.1/tests/data
I'm not familiar with the magic performed by BuildBPF.cmake, but as far
as I can tell, gcc is being invoked with "-g" and no prefix mapping,
so there is no way of stopping the source path(s) from ending in data_source.o.
This patch adds a "bridge" between this .cmake file and bpftrace's
recipe, where I export DEBUG_PREFIX_MAP, so gcc is invoked with the
-ffile-prefix-map flags from OE Core.
The end result is:
$ strings ./build/tests/data/data_source.o | grep "debug\/bpftrace"
/usr/src/debug/bpftrace/0.25.1/tests/data/data_source.c
/usr/src/debug/bpftrace/0.25.1/tests/data
/usr/src/debug/bpftrace/0.25.1/tests/data
/usr/src/debug/bpftrace/0.25.1/tests/data
Signed-off-by: João Marcos Costa <joaomarcos.costa@bootlin.com>
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
bpftrace-ptest requires bpftool which is not compatible with powerpc64.
So remove sub-package bpftrace-ptest for powerpc64 & powerpc64le.
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
* bash and python3 are only needed by the ptest package.
* xz appears to not be needed at all.
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
These recipes depend on clang, and clang being on core
it is better place for these tools to be in a common
layer for now that is meta-oe
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Khem Raj
Joao Marcos Costa
Kai Kang
Peter Kjellerstedt
Khem Raj
Changqing Li