A test program uses pthread_setname_np(), a GNU extension that needs
_GNU_SOURCE defined before <pthread.h> is included to be declared.
AI-Generated: Uses Claude Code
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
nvmetcli imports neither six nor anything that needs it; the runtime
dependency is a leftover from the Python 2 era.
Built for intel-corei7-64.
AI-Generated: Uses Claude Code (Claude Opus 5)
Signed-off-by: Markus Volk <f_l_k@t-online.de>
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
cmake/BuildBPF.cmake compiles the BPF data source with the plain gcc it
finds in PATH (find_program(GCC gcc)) rather than with the cross
compiler, because the BTF encoding step needs gcc plus pahole. The
recipe exports DEBUG_PREFIX_MAP and
0001-cmake-BuildBPF.cmake-introduce-DEBUG_PREFIX_MAP.patch hands it to
that command so the embedded objects do not carry build paths.
DEBUG_PREFIX_MAP also picks up DEBUG_PREFIX_MAP_EXTRA, which is
-fcanon-prefix-map for the gcc toolchain
(meta/classes/toolchain/gcc.bbclass). That option only exists in
GCC >= 13: the cross compiler always has it, the build host's gcc may
not, and the ptest enabled build then fails with
gcc: error: unrecognized command-line option '-fcanon-prefix-map';
did you mean '-fmacro-prefix-map='?
Drop it, the way frr and kernel-selftest already do for the same reason.
The four -ffile-prefix-map= rewrites are all this needs: with the extra
removed tests/data/data_source.o still contains no build paths, only
/usr/src/debug/bpftrace/0.26.1.
Signed-off-by: Khem Raj <raj.khem@gmail.com>
bcc's tools/funccount_example.txt documents tracing a binary that
upstream placed under /home/ubuntu:
# ./funccount -p 1442 /home/ubuntu/contentions:*
Tracing 15 functions for "/home/ubuntu/contentions:*"...
If /home/ubuntu is in the $PATH, then the following command will also work:
That is documentation prose, not a leaked build path, but the buildpaths
QA check flags any packaged file containing the builder's HOME, so on a
host whose HOME is /home/ubuntu it warns twice - once for the copy in
${datadir}/bcc/tools/doc and once for the copy do_install_ptest places
in ${libdir}/tools:
WARNING: bcc-0.37.0-r0 do_package_qa: QA Issue: File
/usr/share/bcc/tools/doc/funccount_example.txt in package bcc contains
a reference to the build host HOME directory. [buildpaths]
WARNING: bcc-0.37.0-r0 do_package_qa: QA Issue: File
/usr/lib/tools/funccount_example.txt in package bcc-ptest contains a
reference to the build host HOME directory. [buildpaths]
Both packaged copies are byte identical to the file in the upstream tree
and contain no reference to TMPDIR, confirming nothing is baked in at
build time. Set OEQA_BUILDPATHS_SKIP as the QA message suggests, which
suppresses only the HOME half of the check; the TMPDIR half still guards
against real build path leaks. oe-core does the same for sudo, perl,
python3-numpy and python3-pytest.
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
Add two new recipes from the CentOS Automotive SIG
boot-time-analysis-tools project to enable boot time profiling
and measurement.
boot-time-analysis-tools:
Python-based toolset for collecting, analyzing and visualizing system
boot timing data from the systemd journal. Provides the 'boot_timings'
CLI utility which queries D-Bus and the systemd journal to produce
structured boot time reports. Depends on python3-dbus and python3-systemd
for runtime journal and D-Bus access.
cntvct-log:
Userspace C utility built with Meson that logs ARM CNTVCT_EL0 virtual
counter timestamps to correlate hardware-level timing with systemd boot
events. Installs cntvct@.service as a systemd template unit (disabled
by default) for on-demand per-instance activation. The service preset
file (98-cntvct-log.preset) is installed for system-preset-based enablement.
Both recipes fetch from the same upstream git repository:
https://gitlab.com/CentOS/automotive/src/boot-time-analysis-tools
Signed-off-by: Chitti Babu Theegala <ctheegal@qti.qualcomm.com>
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
LLVM 23 changed the MCContext constructor to take MCAsmInfo,
MCRegisterInfo and MCSubtargetInfo by reference rather than by pointer,
so bcc no longer builds:
src/cc/bcc_debug.cc:151:68: error: no matching function for call to
'llvm::MCContext::MCContext(...)'
Backport the upstream fix. It is guarded on LLVM_VERSION_MAJOR so older
Clang keeps working. There is no release carrying it yet; v0.37.0 is
still the newest tag.
Co-authored-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
Signed-off-by: Sunil Dora <sunilkumar.dora@windriver.com>
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
Remove assignments to PYPI_PACKAGE where the value is the default value,
that is the recipe name with any python3- prefix removed.
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
A full check-upgrade-status sweep of meta-oe found 121 recipes reporting
UNKNOWN_BROKEN: their upstream version check resolved no version. This
adds the correct check metadata to each so the version check works again.
Fixes, by mechanism:
- wget/tarball recipes: add UPSTREAM_CHECK_URI + UPSTREAM_CHECK_REGEX
pointing at the real release listing (SourceForge files pages, GitHub
releases pages, GNU/ftp mirrors, distro pools).
- git recipes with release tags in a non-default format: add
UPSTREAM_CHECK_GITTAGREGEX matching the actual tag scheme.
- git repos with no tags at all: UPSTREAM_CHECK_COMMITS = "1".
- recipes whose upstream has no checkable release channel, or whose PV
format cannot be compared against upstream tags (CPAN zero-padded
versions, AUTOINC "git" PVs, dash-separated tags the checker cannot
convert): UPSTREAM_VERSION_UNKNOWN = "1" with an explanatory comment.
Also override GITHUB_BASE_URI for libppd's sibling libcupsfilters where the
github-releases class default pointed at a non-existent org (404).
Only version-check metadata is touched; no SRC_URI, SRCREV, PV, or checksum
is changed, so nothing that gets built is affected. Each fix was verified
with devtool check-upgrade-status: 120 of 121 now resolve (MATCH, UPDATE,
COMMITS, or an honestly-declared UNKNOWN). The remaining recipe (libubox)
already has correct metadata and only fails locally because the git://
port to git.openwrt.org is firewalled on the build host.
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
tests/cc passes -DCMAKE_CURRENT_BINARY_DIR="${CMAKE_CURRENT_BINARY_DIR}" to
every test object so the tests can find archive.zip, the debuginfo libraries
and dummy_proc_map.txt at runtime. That put 13 copies of the absolute build
directory into the installed test binary:
QA Issue: File /usr/lib/bcc/ptest/tests/cc/test_libbcc_no_libbpf in package
bcc-ptest contains reference to TMPDIR [buildpaths]
and, on autobuilders whose TMPDIR sits below $HOME, additionally:
QA Issue: ... contains a reference to the build host HOME directory.
The recipe worked around this by installing the assets to ${D}${B}/tests/cc,
i.e. by reproducing the build path inside the image, and by demoting
buildpaths to a warning.
Add a patch introducing a TEST_ASSET_DIR cache variable, defaulting to
CMAKE_CURRENT_BINARY_DIR so the upstream default is unchanged, and point it at
${PTEST_PATH}/tests/cc. The assets are now installed next to the test binaries
and no build path is embedded, so the buildpaths overrides can go away.
Also install dummy_proc_map.txt, which the tests reference but which was never
shipped.
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
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>
0001-Add-ARM64-syscall-prefix-detection-in-C-API.patch
0002-Add-riscv-syscall-prefix-detection-in-C-API.patch
0003-folly-tracing-Remove-x86-specific-naming-from-tracin.patch
0004-folly-tracing-Add-ARM-and-AArch64-support-to-static-.patch
0001-Fix-build-with-LLVM-22.patch
removed since they're included in 0.37.0
Signed-off-by: Wang Mingyu <wangmy@fujitsu.com>
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>
Relocate the recipe from dynamic-layers/selinux/ to the main
meta-oe/recipes-devtools/ directory.
The android-tools recipe (version 29.0.6.r14) was previously restricted
to the selinux dynamic-layer.
Investigation shows that version 29.0.6.r14 does not have a hard dependency
on libselinux for core tool functionality.
(adb, fastboot, and sparse image tools).
- Basic runable test was done for binaries in android-tools-native
- Checked for selinux absense by looking for selinx using $ ldd binary-name
Changes:
- Relocate recipe from dynamic-layers/selinux/ to recipes-devtools/
Signed-off-by: AshishKumar Mishra <ashishkumar.mishra@bmwtechworks.in>
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>
- Labeled adb binary
- Moved adb shell from initrc_t to unconfined_t
- meta-selinux does not provide adb domain added policy in meta-oe
instead of refpolicy: SELinuxProject/refpolicy#1085
Signed-off-by: Gargi Misra <gmisra@qti.qualcomm.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Without xz present, compilation fails with the following error:
| <...>/x86_64-oe-linux-ld: warning: liblzma.so.5, needed by <...>/libbcc.so, not found (try using -rpath or -rpath-link)
| <...>/x86_64-oe-linux-ld: <...>/libbcc.so: undefined reference to `lzma_code@XZ_5.0'
| <...>/x86_64-oe-linux-ld: <...>/libbcc.so: undefined reference to `lzma_end@XZ_5.0'
| <...>/x86_64-oe-linux-ld: <...>/libbcc.so: undefined reference to `lzma_stream_decoder@XZ_5.0'
| collect2: error: ld returned 1 exit status
Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Building android-tools v29.0.6.r14 with glibc 2.43 fails due to ISO C23
changes to strchr(). Add a patch to update the affected libunwind sources
to use const pointer types to fix this build failure.
Signed-off-by: Viswanath Kraleti <viswanath.kraleti@oss.qualcomm.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
This resolves USDT probe test failures on ARM64 platforms.
Without these changes, the .note.stapsdt section containing probe
information was missing entirely on ARM64, causing test failures when
attempting to find and attach to USDT probes in the BCC test suite.
Upstream-Status: Submitted [https://github.com/iovisor/bcc/pull/5491]
Signed-off-by: Harish Sadineni <Harish.Sadineni@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
For the boards with multiple UDC ports, when compiling with meta-selinux
layer adb funtion will be impacted due to below error. Remove the recipe
under dynamic-layers/selinux/ as it's not required anymore, and ensure
adb work normally on the boards with multiple UDC ports.
ls /sys/class/udc/ > /sys/kernel/config/usb_gadget/adb/UDC
ls: write error: Device or resource busy
Signed-off-by: Shoudi Li <shoudil@qti.qualcomm.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
2. Pyrwmem and static-libc build option has been removed in 2.0.
Signed-off-by: Liu Yiding <liuyd.fnst@fujitsu.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
With thingsboard-gateway 3.8.0, the source URI must be set to the
project Git repository, as source releases are no longer provided via
PyPi for this project.
Signed-off-by: Martin Schwan <m.schwan@phytec.de>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Some post-processing options require an argument, otherwise a segfault
will occur:
root@qemux86-64:~# rasdaemon -p --status --ipid
Segmentation fault (core dumped) rasdaemon -p --status --ipid
Backport a patch to fix this issue.
Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Ankur Tyagi
Khem Raj
Markus Volk
Chitti Babu Theegala
Sunil DoraandDeepesh Varatharajan
Ross Burton
Wang Mingyu
Khem Raj
Joao Marcos Costa
AshishKumar Mishra
Gargi Misra
Yi Zhao
Swamil Jain
Abhilasha Manna
Kai Kang
Peter Kjellerstedt
Gyorgy Sarvari
Viswanath Kraleti
Harish Sadineni
Shoudi Li
Liu Yiding
Martin Schwan
Weisser, Pascal