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>
And make the dwarves use it, so that we can remove duplicate strings in
a multi-CU file (vmlinux anyone?) and have it ready for insertion in a
compressed DWARF format with just the types, or better, CTF or some new
compressed debugging info format.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
So that one can get an skeleton from where a function can be
reimplemented, or a probe can be written to attach to a tracepoint.
Right now it will only expand the types for
struct/union/typedef/enumeration types, but it is a good start.
[acme@doppio pahole]$ pfunct --expand_types --function inet6_ioctl ipv6.ko > a.c
[acme@doppio pahole]$ echo "int main(void) { return 0; }" >> a.c
[acme@doppio pahole]$ gcc -Wall -g a.c -o a
[acme@doppio pahole]$ grep ^#include a.c
[acme@doppio pahole]$
No errors, no includes.
This is present in ctracer, where we don't want to _require_ any header
files, just the object file with the function we want to probe. From
there we get the function signature, and reconstruct the types needed to
access members of structs passed as parameters.
We still need to add padding to reconstruct __attribute__ alignment
effects.
Also, if we can detect what are the exact members accessed in the probe,
we can reconstruct just what is needed to access those members,
hopefully reducing the time needed for gcc to digest the resulting
source code. And also reducing the size of the output, which can
hopefully be interesting to help focus on what the probe is doing.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
In libdwarves.so well continue using DW_TAG_ entries and types for now, but its
becoming non-DWARF specific as will be demonstrated with the introduction of
ctf_loader.c in the upcoming csets.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Now at creation time we specify if the strings must be allocated or if using
the pointer directly.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>