For the threaded code we want to access strings in tags at the same time
that the string table may grow in another thread making the previous
pointer invalid, so, to avoid excessive locking, use plain strings.
The way the tools work will either consume the just produced CU straight
away or keep just one copy of each data structure when we keep all CUs
in memory, so lets try stopping using strings_t for strings.
For the namespace->name case we get the bonus of removing another
user of dwarves__active_loader.
This covers unions, enums, structs and classes.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
For the threaded code we want to access strings in tags at the same time
that the string table may grow in another thread making the previous
pointer invalid, so, to avoid excessive locking, use plain strings.
The way the tools work will either consume the just produced CU straight
away or keep just one copy of each data structure when we keep all CUs
in memory, so lets try stopping using strings_t for strings.
For the class_member->name case we get the bonus of removing another
user of dwarves__active_loader.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
For the threaded code we want to access strings in tags at the same time
that the string table may grow in another thread making the previous
pointer invalid, so, to avoid excessive locking, use plain strings.
The way the tools work will either consume the just produced CU straight
away or keep just one copy of each data structure when we keep all CUs
in memory, so lets try stopping using strings_t for strings.
For the parameter->name case we get the bonus of removing a user of
dwarves__active_loader.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
For the threaded code we want to access strings in tags at the same time
that the string table may grow in another thread making the previous
pointer invalid, so, to avoid excessive locking, use plain strings.
The way the tools work will either consume the just produced CU straight
away or keep just one copy of each data structure when we keep all CUs
in memory, so lets try stopping using strings_t for strings.
For the base_type->name case we get the bonus of removing some more
functions related base types and a user of dwarves__active_loader.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
It was never fully functional and now its getting in the way of further
improvements for loading/encoding BTF and loading DWARF.
Eventually we can use Oracle's libctf library to add an encoder.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
It looked for an index into a string table, a string_t, but since for
multithreading we'd be growing the string table while looking up stuff,
we'd be looking at realloc'ed memory, so lets move to stable char
pointer strings.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
It looked for an index into a string table, a string_t, but since for
multithreading we'd be growing the string table while looking up stuff,
we'd be looking at realloc'ed memory, so lets move to stable char
pointer strings.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
For the threaded code we want to access strings in tags at the same time
that the string table may grow in another thread making the previous
pointer invalid, so, to avoid excessive locking, use plain strings.
The way the tools work will either consume the just produced CU straight
away or keep just one copy of each data structure when we keep all CUs
in memory, so lets try stopping using strings_t for strings.
For the function->name case we get the bonus of removing the need of a
debug_fmt_ops->function() callback receiving the 'cu', just access the
string directly.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
For the threaded code we want to access strings in tags at the same time
that the string table may grow in another thread making the previous
pointer invalid, so, to avoid excessive locking, use plain strings.
The way the tools work will either consume the just produced CU straight
away or keep just one copy of each data structure when we keep all CUs
in memory, so lets try stopping using strings_t for strings.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
For the threaded code we want to access strings in tags at the same time
that the string table may grow in another thread making the previous
pointer invalid, so, to avoid excessive locking, use plain strings.
The way the tools work will either consume the just produced CU straight
away or keep just one copy of each data structure when we keep all CUs
in memory, so lets try stopping using strings_t for strings.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Using the same command line option as 'make' and 'ninja': -j.
Unfortunately the argp parser in glibc expects a '=' for single letter
args, so it is:
$ pahole -j=10
or, like with 'make':
$ make --jobs=10
This is unwired at the moment, probably I'll reorder the patch, but for
testing, add it first.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The '-j' option, to generate detached BTF files wasn't published in any
tagged release, so leave it as just --btf_encode_detached and make '-j'
available for specifying the number of jobs/threads, as is the case with
'make -j', 'ninja -j', etc.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Paving the way for having multiple threads creating CUs and possibly
adding them to cus->cus.
The mutex will also be used to ask elfutils-libdwfl to read the next CU,
after a thread finishes reading one.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
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>
This reverts commit de3a7f9125.
Andrii reports that this cset is breaking the CI, as reported at:
https://travis-ci.com/github/libbpf/libbpf/jobs/514329152
So revert it while investigation about the root cause continues.
Reported-by: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The ->filename only points out to the ELF file when we're not writing to
a raw, detached BTF file, so reuse it to store the detached filename
when using that mode.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
We were passing two 'btf_encoder' fields, so pass just the btf_encoder
instance. Ditch the unused 'flags' arg.
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>
Andrii reported that __unused is a field in /usr/include/bits/stat.h and
vmlinux.h (generated by bpftool), so use the Linux kernel jargon for
this and rename it to '__maybe_unused'.
Reported-by: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The original "libbpf: allow to use packaged version" had a symlink as
suggested during review, that got mistakenly dropped by Arnaldo when
applying the patch by hand to fixup conflicts, add it back.
Committer notes:
This caused mixups with libbpf-devel files that ended up breaking the
build as reported by Andrii.
Reported-by: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Tested-by: Acked-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Luca Boccassi <bluca@debian.org>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Added a section in README to give details about use of
-DBUILD_SHARED_LIBS cmake option and existing documentation reformatted
to accommodate this.
Signed-off-by: Deepak Kumar Mishra <deepakkumar.mishra@arm.com>
Cc: Qais Yousef <qais.yousef@arm.com>
Cc: dwarves@vger.kernel.org
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>
Its available, has the same value, use the per-instance 'verbose' member
instead of the global, this should be the last use of that global, time
to ditch it.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Arnaldo Carvalho de Melo
Luca Boccassi
Deepak Kumar Mishra