This is just for CIs to be able to, building from master, encode
variables, that are disabled in the Linux kernel but fixed with what
came after v1.21.
Requested-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Required for the new API btf__add_float().
Signed-off-by: Luca Boccassi <bluca@debian.org>
Reported-by: Arnaldo Carvalho de Melo <acme@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@kernel.org>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
If using the system library was explicitly requested, ensure it is present
and fail the build if it is not, rather than falling back to the
embedded version (same for pkg-config).
Signed-off-by: Luca Boccassi <bluca@debian.org>
Requested-by: Arnaldo Carvalho de Melo <acme@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Add a new CMake option, LIBBPF_EMBEDDED, to switch between the embedded
version and the system version (searched via pkg-config) of libbpf. Set
the embedded version as the default.
Committer testing:
The default build works as before:
⬢[acme@toolbox pahole]$ rm -rf build ; mkdir build ; cd build ; cmake -DCMAKE_BUILD_TYPE=Release .. ; cd ..
-- The C compiler identification is GNU 11.1.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Checking availability of DWARF and ELF development libraries
-- Looking for dwfl_module_build_id in elf
-- Looking for dwfl_module_build_id in elf - found
-- Found dwarf.h header: /usr/include
-- Found elfutils/libdw.h header: /usr/include
-- Found libdw library: /usr/lib64/libdw.so
-- Found libelf library: /usr/lib64/libelf.so
-- Checking availability of DWARF and ELF development libraries - done
-- Found ZLIB: /usr/lib64/libz.so (found version "1.2.11")
-- Submodule update
-- Submodule update - done
-- Performing Test HAVE_REALLOCARRAY_SUPPORT
-- Performing Test HAVE_REALLOCARRAY_SUPPORT - Success
-- Configuring done
-- Generating done
-- Build files have been written to: /var/home/acme/git/pahole/build
⬢[acme@toolbox pahole]$ make -j28 -C build
make: Entering directory '/var/home/acme/git/pahole/build'
make[1]: Entering directory '/var/home/acme/git/pahole/build'
make[2]: Entering directory '/var/home/acme/git/pahole/build'
Scanning dependencies of target bpf
make[2]: Leaving directory '/var/home/acme/git/pahole/build'
make[2]: Entering directory '/var/home/acme/git/pahole/build'
[ 5%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/btf.c.o
[ 5%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/bpf_prog_linfo.c.o
[ 5%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/bpf.c.o
[ 7%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/libbpf_errno.c.o
<SNIP>
make[2]: Leaving directory '/var/home/acme/git/pahole/build'
[ 98%] Built target ctracer
[100%] Linking C executable pahole
make[2]: Leaving directory '/var/home/acme/git/pahole/build'
[100%] Built target pahole
make[1]: Leaving directory '/var/home/acme/git/pahole/build'
make: Leaving directory '/var/home/acme/git/pahole/build'
⬢[acme@toolbox pahole]$ ldd build/pahole
linux-vdso.so.1 (0x00007ffcf4d92000)
libdwarves_reorganize.so.1 => /var/home/acme/git/pahole/build/libdwarves_reorganize.so.1 (0x00007f059c289000)
libdwarves.so.1 => /var/home/acme/git/pahole/build/libdwarves.so.1 (0x00007f059c226000)
libdw.so.1 => /lib64/libdw.so.1 (0x00007f059c186000)
libelf.so.1 => /lib64/libelf.so.1 (0x00007f059c16b000)
libz.so.1 => /lib64/libz.so.1 (0x00007f059c151000)
libc.so.6 => /lib64/libc.so.6 (0x00007f059bf82000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f059bf79000)
libzstd.so.1 => /lib64/libzstd.so.1 (0x00007f059be83000)
liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f059be57000)
libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f059be44000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f059be23000)
/lib64/ld-linux-x86-64.so.2 (0x00007f059c290000)
⬢[acme@toolbox pahole]$
Then, trying to use the libbpf-devel present in Fedora 34:
⬢[acme@toolbox pahole]$ rm -rf build ; mkdir build ; cd build ; cmake -DCMAKE_BUILD_TYPE=Release -DLIBBPF_EMBEDDED=Off .. ; cd ..
-- The C compiler identification is GNU 11.1.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Found PkgConfig: /usr/bin/pkg-config (found version "1.7.3")
-- Checking for module 'libbpf>=0.3.0'
-- Found libbpf, version 0.3.0
-- Checking availability of DWARF and ELF development libraries
-- Looking for dwfl_module_build_id in elf
-- Looking for dwfl_module_build_id in elf - found
-- Found dwarf.h header: /usr/include
-- Found elfutils/libdw.h header: /usr/include
-- Found libdw library: /usr/lib64/libdw.so
-- Found libelf library: /usr/lib64/libelf.so
-- Checking availability of DWARF and ELF development libraries - done
-- Found ZLIB: /usr/lib64/libz.so (found version "1.2.11")
-- Submodule update
-- Submodule update - done
-- Performing Test HAVE_REALLOCARRAY_SUPPORT
-- Performing Test HAVE_REALLOCARRAY_SUPPORT - Success
-- Configuring done
-- Generating done
-- Build files have been written to: /var/home/acme/git/pahole/build
⬢[acme@toolbox pahole]$ m
make: Entering directory '/var/home/acme/git/pahole/build'
make[1]: Entering directory '/var/home/acme/git/pahole/build'
make[2]: Entering directory '/var/home/acme/git/pahole/build'
Scanning dependencies of target dwarves
make[2]: Leaving directory '/var/home/acme/git/pahole/build'
make[2]: Entering directory '/var/home/acme/git/pahole/build'
[ 2%] Building C object CMakeFiles/dwarves.dir/dwarves.c.o
[ 5%] Building C object CMakeFiles/dwarves.dir/dwarves_fprintf.c.o
[ 7%] Building C object CMakeFiles/dwarves.dir/gobuffer.c.o
<SNIP>
[ 33%] Building C object CMakeFiles/dwarves.dir/rbtree.c.o
/var/home/acme/git/pahole/btf_encoder.c:84:10: error: ‘BTF_KIND_FLOAT’ undeclared here (not in a function); did you mean ‘BTF_KIND_INT’?
84 | [BTF_KIND_FLOAT] = "FLOAT",
| ^~~~~~~~~~~~~~
| BTF_KIND_INT
/var/home/acme/git/pahole/btf_encoder.c:84:10: error: array index in initializer not of integer type
/var/home/acme/git/pahole/btf_encoder.c:84:10: note: (near initialization for ‘btf_kind_str’)
/var/home/acme/git/pahole/btf_encoder.c:84:35: warning: excess elements in array initializer
84 | [BTF_KIND_FLOAT] = "FLOAT",
| ^~~~~~~
/var/home/acme/git/pahole/btf_encoder.c:84:35: note: (near initialization for ‘btf_kind_str’)
/var/home/acme/git/pahole/btf_encoder.c: In function ‘btf_encoder__add_float’:
/var/home/acme/git/pahole/btf_encoder.c:224:22: warning: implicit declaration of function ‘btf__add_float’; did you mean ‘btf__add_var’? [-Wimplicit-function-declaration]
224 | int32_t id = btf__add_float(encoder->btf, name, BITS_ROUNDUP_BYTES(bt->bit_size));
| ^~~~~~~~~~~~~~
| btf__add_var
/var/home/acme/git/pahole/btf_loader.c: In function ‘btf__load_types’:
/var/home/acme/git/pahole/btf_loader.c:455:22: error: ‘BTF_KIND_FLOAT’ undeclared (first use in this function); did you mean ‘BTF_KIND_INT’?
455 | case BTF_KIND_FLOAT:
| ^~~~~~~~~~~~~~
| BTF_KIND_INT
/var/home/acme/git/pahole/btf_loader.c:455:22: note: each undeclared identifier is reported only once for each function it appears in
make[2]: *** [CMakeFiles/dwarves.dir/build.make:173: CMakeFiles/dwarves.dir/btf_encoder.c.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: *** [CMakeFiles/dwarves.dir/build.make:186: CMakeFiles/dwarves.dir/btf_loader.c.o] Error 1
make[2]: Leaving directory '/var/home/acme/git/pahole/build'
make[1]: *** [CMakeFiles/Makefile2:173: CMakeFiles/dwarves.dir/all] Error 2
make[1]: Leaving directory '/var/home/acme/git/pahole/build'
make: *** [Makefile:149: all] Error 2
make: Leaving directory '/var/home/acme/git/pahole/build'
⬢[acme@toolbox pahole]$
It doesn't build as libbpf is old and doesn't have support for
BTF_KIND_FLOAT.
Signed-off-by: Luca Boccassi <bluca@debian.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: dwarves@vger.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
This reverts commit 82749180b2.
Getting in the way of releasing 1.20, breaking the build of a dwarves
rpm when a libbpf package is installed in a fedora 33 system:
In file included from /home/acme/rpmbuild/BUILD/dwarves-1.20/strings.c:7:
/home/acme/rpmbuild/BUILD/dwarves-1.20/pahole_strings.h:9:10: fatal error: bpf/btf.h: No such file or directory
9 | #include <bpf/btf.h>
| ^~~~~~~~~~~
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
When calling cmake on the build dir we got this on fedora rawhide (cmake 3.19.4):
CMake Deprecation Warning at CMakeLists.txt:2 (cmake_minimum_required):
Compatibility with CMake < 2.8.12 will be removed from a future version of
CMake.
Update the VERSION argument <min> value or use a ...<max> suffix to tell
CMake that the project does not need compatibility with older versions.
So bump it.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Add a new CMake option, LIBBPF_EMBEDDED, to switch between the
embedded version and the system version (searched via pkg-config)
of libbpf. Set the embedded version as the default.
Signed-off-by: Luca Boccassi <bluca@debian.org>
Cc: dwarves@vger.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Nothing changes now, this continues to work just the same:
$ pahole --version
v1.18
$ pfunct --version
v1.18
$
This just paves the way for us to have a '--numeric-version' that will
do away with the dot and the leading 'v' and that can be used in
Makefiles to check if the required minimum version is available, to
avoid what we have now in the Linux kernel:
config PAHOLE_HAS_SPLIT_BTF
def_bool $(success, test `$(PAHOLE) --version | sed -E 's/v([0-9]+)\.([0-9]+)/\1\2/'` -ge "119")
With the next cset we'll be able to do just:
test `$(PAHOLE) --numeric-version` -ge "119"
Cc: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Now that libbpf is used to implement deduplicated strings container, all
of the binaries will need linux/btf.h header to compile properly. libbpf
is distributed with its own copies of Linux UAPI headers, so use them
during compilation.
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Cc: dwarves@vger.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
This was detected with:
In file included from /home/acme/git/pahole/strings.h:9,
from /usr/include/string.h:432,
from /home/acme/git/pahole/lib/bpf/src/libbpf_common.h:12,
from /home/acme/git/pahole/lib/bpf/src/libbpf.h:20,
from /home/acme/git/pahole/lib/bpf/src/ringbuf.c:20:
/home/acme/git/pahole/lib/bpf/src/btf.h:33:11: error: expected ‘;’ before ‘void’
33 | LIBBPF_API void btf__free(struct btf *btf);
| ^~~~~
| ;
libbpf_common.h has:
#include <string.h>
#ifndef LIBBPF_API
#define LIBBPF_API __attribute__((visibility("default")))
#endif
So before defining LIBBPF_API it includes libc's string.h that in turn
includes pahole's strings.h and now it includes:
#include "lib/bpf/src/btf.h"
That will need the LIBBPF_API, b00m.
So lets just rename pahole's strings.h to pahole_strings.h to avoid this
pitfall.
This patch was moved to before this problem takes place so that we keep
everything bisectable.
Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
We need that as the fix in upstream libbpf is in the
tools/lib/bpf/Makefile, that isn't used when building libbpf as part of
pahole, see:
"Makefile: back-port _FILE_OFFSET_BITS=64 and _LARGEFILE64_SOURCE to Makefile"
4a50ceb043
That refers to this in the kernel sources:
71dd77fd4bf7 ("libbpf: use LFS (_FILE_OFFSET_BITS) instead of direct mmap2 syscall")
Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Julia Kartseva <hex@fb.com>
Cc: Yonghong Song <yhs@fb.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
To avoid using /usr/include/linux/btf.h, as it has:
[acme@quaco pahole]$ grep ^# /usr/include/linux/btf.h | head -2
#ifndef __LINUX_BTF_H__
#define __LINUX_BTF_H__
[acme@quaco pahole]$
While:
[acme@quaco pahole]$ grep ^# lib/bpf/include/uapi/linux/btf.h | head -2
#ifndef _UAPI__LINUX_BTF_H__
#define _UAPI__LINUX_BTF_H__
[acme@quaco pahole]$
Then when both get included we get duplicate definitions, to avoid that
put lib/bpf/include/uapi/ first in the include path for libbdwarves.
Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
As libbpf is not yet widely available, it's safer to statically link it
into libdwarves for now. Easiest way to define that in cmake is through
OBJECT library with PIC.
Committer testing:
$ file build/pahole
build/pahole: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=666c97e5763ac0f4c5eff229be1532f1e60195e6, with debug_info, not stripped
$ ldd build/pahole
linux-vdso.so.1 (0x00007ffe5fdf8000)
libdwarves_reorganize.so.1 => /home/acme/git/pahole/build/libdwarves_reorganize.so.1 (0x00007f1c84fa4000)
libdwarves.so.1 => /home/acme/git/pahole/build/libdwarves.so.1 (0x00007f1c84f5e000)
libdw.so.1 => /lib64/libdw.so.1 (0x00007f1c84eee000)
libelf.so.1 => /lib64/libelf.so.1 (0x00007f1c84ed4000)
libz.so.1 => /lib64/libz.so.1 (0x00007f1c84eba000)
libc.so.6 => /lib64/libc.so.6 (0x00007f1c84cf4000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f1c84cec000)
liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f1c84cc3000)
libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f1c84cb0000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1c84fad000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f1c84c8e000)
$
$ nm build/libdwarves.so.1.0.0 | grep b[pt]f__
0000000000028aae T btf__dedup
0000000000027d44 T btf__fd
0000000000027a37 T btf__find_by_name
0000000000027ad9 T btf__free
0000000000027da8 T btf__get_from_id
0000000000027f6c T btf__get_map_kv_tids
0000000000027739 T btf__get_nr_types
0000000000027d55 T btf__get_raw_data
0000000000027c2e T btf__load
0000000000027d77 T btf__name_by_offset
0000000000027b36 T btf__new
00000000000277eb T btf__resolve_size
0000000000027960 T btf__resolve_type
000000000002774a T btf__type_by_id
$
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Suggested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexei Starovoitov <ast@fb.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Cc: Yonghong Song <yhs@fb.com>
Cc: bpf@vger.kernel.org
Cc: dwarves@vger.kernel.org
Cc: kernel-team@fb.com
[ split from a larger patch ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
We need to link with libbpf, that is not yet generally available, so we
need to link it into libdwarves for now, to do that we need to use the
OBJECT library with PIC, and that requires we use at least cmake version
2.8.8, so bump the minimum required cmake version.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Cc: Alexei Starovoitov <ast@fb.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Cc: Yonghong Song <yhs@fb.com>
Cc: bpf@vger.kernel.org
Cc: dwarves@vger.kernel.org
Cc: kernel-team@fb.com
[ split from a larger patch ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
This change allows to use libbpf definitions and APIs from pahole.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Cc: Alexei Starovoitov <ast@fb.com>
Cc: Martin KaFai Lau <kafai@fb.com>
Cc: Yonghong Song <yhs@fb.com>
Cc: dwarves@vger.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
This patch introduces BPF Type Format (BTF).
BTF (BPF Type Format) is the meta data format which describes
the data types of BPF program/map. Hence, it basically focus
on the C programming language which the modern BPF is primary
using. The first use case is to provide a generic pretty print
capability for a BPF map.
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The current release is v1.10, but CMakeLists.txt had just v1.9, fix it.
Reported-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
currently mandriva has a packaging script which checks for uneeded linking in
package built files. For dwarves, it displays:
Warning: unused libraries in /usr/lib64/libdwarves_reorganize.so.1.0.0: libdw.so.1
libelf.so.1
libz.so.1
Warning: unused libraries in /usr/lib64/libdwarves_emit.so.1.0.0: libdw.so.1
libelf.so.1
libz.so.1
Warning: unused libraries in /usr/bin/ctracer: libz.so.1
libdw.so.1
Warning: unused libraries in /usr/bin/syscse: libdw.so.1
libelf.so.1
libz.so.1
Warning: unused libraries in /usr/bin/pglobal: libdw.so.1
libelf.so.1
libz.so.1
Warning: unused libraries in /usr/bin/pdwtags: libdw.so.1
libelf.so.1
libz.so.1
Warning: unused libraries in /usr/bin/prefcnt: libdw.so.1
libelf.so.1
libz.so.1
Warning: unused libraries in /usr/bin/pfunct: libz.so.1
libdw.so.1
Warning: unused libraries in /usr/bin/pahole: libz.so.1
libdw.so.1
libelf.so.1
Warning: unused libraries in /usr/bin/dtagnames: libdw.so.1
libelf.so.1
libz.so.1
Warning: unused libraries in /usr/bin/codiff: libdw.so.1
libelf.so.1
libz.so.1
The patch below fixes the issue (removing uneeded specified libraries and using
LINK_INTERFACE_LIBRARIES property, see
http://www.cmake.org/Wiki/CMake_FAQ#Why_are_libraries_linked_to_my_shared_library_included_when_something_links_to_it.3F)
Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
CMP0005
Preprocessor definition values are now escaped automatically.
This policy determines whether or not CMake should generate escaped
preprocessor definition values added via add_definitions.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
That is used by cus__find_function_by_addr & cu__func_function_by_addr.
First user is pfunct --addr, but this is really for pfunct --annotate, that
will process a perf.data file generated by 'perf report', load the debugging
info and regenerate the functions (pfunct -TVi like) that had hits, using
libdisasm to show the assembly code, etc.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
In reponse to https://bugzilla.redhat.com/show_bug.cgi?id=497285 I
included the header files that are needed by the dwarves*.h files
and moved them to /usr/include/dwarves.h.
The CTF work is not completed yet, but the non-CTF related improvements
(progressive loading of CUs, etc) are worth a release till I can get back to
dedicate solid time for developing these tools again.
Reported-by: Masatake YAMATO <yamato@redhat.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
We will need this when encoding the CTF functions section. Things like lookup
a function by its address when converting from a DW_TAG_subprogram to a CTF
function, for instance.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
"pahole -Z foo" will create foo.SUNW_ctf, that if objcopy
--add-section'ed to the right word-sized object will work, sans VARARGS,
that will get fixed soon (as in, probably, tomorrow).
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>