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>
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>
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>
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>
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>
Update the systemd service file to reflect the changes of the source
repository.
Add a user and group "thingsboard_gateway" which the service runs under,
instead of root.
Store temporary files, like logs, in /var and make use of the newly
created user and group.
Additionally, the service should start after and wants a network
connection to be online, not just be activated.
Signed-off-by: Martin Schwan <m.schwan@phytec.de>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Replace the outdated configuration files with the ones found the source
repository of thingsboard-gateway. This makes sure, the configuration
file examples stay up-to-date in future versions.
Signed-off-by: Martin Schwan <m.schwan@phytec.de>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Add all missing runtime dependencies that are required by
thingsboard-gateway. Since thingsboard-gateway tries to install missing
dependencies via pip and fails to do so, install the dependencies
system-wide beforehand.
Signed-off-by: Martin Schwan <m.schwan@phytec.de>
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>
Earlier both libdrm[1] and kmsxx[2] projects used to provide a binary
program called kmstest. To avoid the clash, the kmsxx recipe was
updated to rename this binary to kmsxxtest during installation. However
libdrm project has now removed kmstest[3] and hence there is no clash
in naming anymore, so revert back to original name of binary i.e.
kmstest.
[1]: https://gitlab.freedesktop.org/mesa/libdrm.git
[2]: https://github.com/tomba/kmsxx
[3]: https://gitlab.freedesktop.org/mesa/libdrm.git
commit: 2b997bb4bb688be00620887c8646ff24ccb9396b
Signed-off-by: Swamil Jain <s-jain1@ti.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Please see
https://git.yoctoproject.org/poky/commit/?id=4dd321f8b83afecd962393101b2a6861275b5265
for what changes are needed, and sed commands that can be used to make them en masse.
I've verified that bitbake -c patch world works with these, but did not run a world
build; the majority of recipes shouldn't need further fixups, but if there are
some that still fall out, they can be fixed in followups.
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Khem Raj
Chitti Babu Theegala
Sunil DoraandDeepesh Varatharajan
Ross Burton
Wang Mingyu
Ankur Tyagi
Khem Raj
Joao Marcos Costa
Yi Zhao
Swamil Jain
Kai Kang
Peter Kjellerstedt
Gyorgy Sarvari
Harish Sadineni
Liu Yiding
Martin Schwan
Weisser, Pascal
Changqing Li
Alexander Kanavin