* ANNOUNCE: pahole v1.22 (Multithreaded DWARF Loading, detached BTF encoding) @ 2021-08-23 21:25 Arnaldo Carvalho de Melo 2021-08-23 21:55 ` Arnaldo Carvalho de Melo 2021-12-08 13:54 ` ANNOUNCE: pahole v1.23 (BTF tags and alignment inference) Arnaldo Carvalho de Melo 0 siblings, 2 replies; 15+ messages in thread From: Arnaldo Carvalho de Melo @ 2021-08-23 21:25 UTC (permalink / raw) To: dwarves Cc: Linux Kernel Mailing List, bpf, Jiri Olsa, Jan Engelhardt, Domenico Andreoli, Matthias Schwarzott, Mark Wieelard, Andrii Nakryiko, Deepak Kumar Mishra, Luca Boccassi, Martin KaFai Lau, Sevan Janiyan, Shuyi Cheng Hi, The v1.22 release of pahole and its friends is out, this time the main new features are the ability to encode BTF to a separate file and Multithreaded DWARF loading. Lots of cleanups and improvements resulted from preparing for multithreading. Please see the changes-1.22 file in the source tree and at the end of this message for a detailed list of improvements. Next step is to multithread BTF encoding, but even without that the time taken tp encode the kernel BTF information now is slashed by over 50%. The before/after 'perf stat' output for each of the improvements can be found in the project git commit log messages. The non-cross build set of containers used to test build the Linux perf tools is now being used to make sure pahole doesn't build regresses. Thanks as well to Andrii for putting in place a CI job for pahole at https://github.com/libbpf/libbpf/actions/workflows/pahole.yml. Main git repo: git://git.kernel.org/pub/scm/devel/pahole/pahole.git Mirror git repo: https://github.com/acmel/dwarves.git tarball + gpg signature: https://fedorapeople.org/~acme/dwarves/dwarves-1.21.tar.xz https://fedorapeople.org/~acme/dwarves/dwarves-1.21.tar.bz2 https://fedorapeople.org/~acme/dwarves/dwarves-1.21.tar.sign Thanks a lot to all the contributors and distro packagers, you're on the CC list, I appreciate a lot the work you put into these tools, Best Regards, - Arnaldo pahole: - Allow encoding BTF to a separate BTF file (detached) instead of to a new ".BTF" ELF section in the file being encoded (vmlinux usually). - Introduce -j/--jobs option to specify the number of threads to use. Without arguments means one thread per CPU. So far used for the DWARF loader, will be used as well for the BTF encoder. - Show all different types with the same name, not just the first one found. - Introduce sorted type output (--sort), needed with multithreaded DWARF loading, to use with things like 'btfdiff' that expects the output from DWARF and BTF types to be comparable using 'diff'. - Stop assuming that reading from stdin means pretty printing as this broke pre-existing scripts, introduce a explicit --prettify command line option. - Improve type resolution for the --header command line option. - Disable incomplete CTF encoder, this needs to be done using the external libctf library. - Do not consider the ftrace filter when encoding BTF for kernel functions. - Add --kabi_prefix to avoid deduplication woes when using _RH_KABI_REPLACE(), - Add --with_flexible_array to show just types with flexible arrays. DWARF Loader: - Multithreaded loading, requires elfutils >= 0.178. - Lock calls to non-thread safe elfutils' libdw functions (dwarf_decl_file() and dwarf_decl_line()) - Change hash table size to one that performs better with current typical vmlinux files. - Allow tweaking the hash table size from the command line. - Stop allocating memory for strings obtained from libdw, just defer freeing the Dwfl handler so that references to its strings can be safely kept. - Use a frontend cache for the latest lookup result. - Allow ignoring some DWARF tags when loading for encoding BTF, as BTF doesn't have equivalents for things like DW_TAG_inline_expansion and DW_TAG_label. - Allow ignoring some DWARF tag attributes, such as DW_AT_alignment, not used when encoding BTF. - Do not query for non-C attributes when loading a C language CU (compilation unit). BTF encoder: - Preparatory work for multithreaded encoding, the focus for 1.23. btfdiff: - Support diffing against a detached BTF file, e.g.: 'btfdiff vmlinux vmlinux.btf' - Support multithreaded DWARF loading, using the new pahole --sort option to have the output from both BTF and DWARF sorted and thus comparable via 'diff'. Build: - Support building with libc libraries lacking either obstacks or argp, such as Alpine Linux's musl libc. - Support systems without getconf() to obtain the data cacheline size, such as musl libc. - Add a buildcmd.sh for test builds, tested using the same set of containers used for testing the Linux kernel perf tools. - Enable selecting building with a shared libdwarves library or statically. - Allow to use the libbpf package found in distributions instead of with the accompanying libbpf git submodule. Cleanups: - Address lots of compiler warnings accumulated by not using -Wextra, it'll be added in the next release after allowing not to use it to build libbpf. - Address covscan report issues. Documentation: - Improve the --nr_methods/-m pahole man page entry. - Clarify that currently --nr_methods doesn't work together witn -C. Tests: $ export BUILD_TARBALL=http://192.168.100.2/pahole/dwarves-1.22.tar.xz $ export BUILD_CMD=buildcmd.sh $ time dm -X 1 3.78 almalinux:8 : Ok gcc (GCC) 8.4.1 20200928 (Red Hat 8.4.1-1) , clang version 11.0.0 (Red Hat 11.0.0-1.module_el8.4.0+2107+39fed697) 2 5.07 alpine:3.12 : Ok gcc (Alpine 9.3.0) 9.3.0 , Alpine clang version 10.0.0 (https://gitlab.alpinelinux.org/alpine/aports.git 7445adce501f8473efdb93b17b5eaf2f1445ed4c) 3 5.48 alpine:3.13 : Ok gcc (Alpine 10.2.1_pre1) 10.2.1 20201203 , Alpine clang version 10.0.1 4 5.68 alpine:3.14 : Ok gcc (Alpine 10.3.1_git20210424) 10.3.1 20210424 , Alpine clang version 11.1.0 5 5.99 alpine:edge : Ok gcc (Alpine 10.3.1_git20210625) 10.3.1 20210625 , Alpine clang version 11.1.0 6 4.27 alt:p8 : Ok x86_64-alt-linux-gcc (GCC) 5.3.1 20151207 (ALT p8 5.3.1-alt3.M80P.1) , clang version 3.8.0 (tags/RELEASE_380/final) 7 4.27 alt:p9 : Ok x86_64-alt-linux-gcc (GCC) 8.4.1 20200305 (ALT p9 8.4.1-alt0.p9.1) , clang version 10.0.0 8 5.07 alt:sisyphus : Ok x86_64-alt-linux-gcc (GCC) 10.2.1 20210313 (ALT Sisyphus 10.2.1-alt3) , clang version 10.0.1 9 4.67 amazonlinux:1 : Ok gcc (GCC) 7.2.1 20170915 (Red Hat 7.2.1-2) , clang version 3.6.2 (tags/RELEASE_362/final) 10 4.27 amazonlinux:2 : Ok gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-13) , clang version 11.1.0 (Amazon Linux 2 11.1.0-1.amzn2.0.2) 11 4.48 centos:8 : Ok gcc (GCC) 8.4.1 20200928 (Red Hat 8.4.1-1) , clang version 11.0.0 (Red Hat 11.0.0-1.module_el8.4.0+587+5187cac0) 12 4.48 centos:stream : Ok gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-3) , clang version 12.0.0 (Red Hat 12.0.0-1.module_el8.5.0+840+21214faf) 13 4.18 clearlinux:latest : Ok gcc (Clear Linux OS for Intel Architecture) 11.2.1 20210816 releases/gcc-11.2.0-71-g4a414ac2a5 , clang version 11.1.0 14 4.88 debian:9 : Ok gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 , clang version 3.8.1-24 (tags/RELEASE_381/final) 15 4.79 debian:10 : Ok gcc (Debian 8.3.0-6) 8.3.0 , clang version 7.0.1-8+deb10u2 (tags/RELEASE_701/final) 16 4.18 debian:11 : Ok gcc (Debian 10.2.1-6) 10.2.1 20210110 , Debian clang version 11.0.1-2 17 4.27 debian:experimental : Ok gcc (Debian 10.2.1-6) 10.2.1 20210110 , Debian clang version 11.0.1-2 18 3.77 fedora:22 : Ok gcc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6) , clang version 3.5.0 (tags/RELEASE_350/final) 19 3.97 fedora:23 : Ok gcc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6) , clang version 3.7.0 (tags/RELEASE_370/final) 20 4.17 fedora:24 : Ok gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1) , clang version 3.8.1 (tags/RELEASE_381/final) 21 4.37 fedora:25 : Ok gcc (GCC) 6.4.1 20170727 (Red Hat 6.4.1-1) , clang version 3.9.1 (tags/RELEASE_391/final) 22 4.48 fedora:26 : Ok gcc (GCC) 7.3.1 20180130 (Red Hat 7.3.1-2) , clang version 4.0.1 (tags/RELEASE_401/final) 23 4.28 fedora:27 : Ok gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-6) , clang version 5.0.2 (tags/RELEASE_502/final) 24 4.47 fedora:28 : Ok gcc (GCC) 8.3.1 20190223 (Red Hat 8.3.1-2) , clang version 6.0.1 (tags/RELEASE_601/final) 25 4.37 fedora:29 : Ok gcc (GCC) 8.3.1 20190223 (Red Hat 8.3.1-2) , clang version 7.0.1 (Fedora 7.0.1-6.fc29) 26 4.28 fedora:30 : Ok gcc (GCC) 9.3.1 20200408 (Red Hat 9.3.1-2) , clang version 8.0.0 (Fedora 8.0.0-3.fc30) 27 4.07 fedora:31 : Ok gcc (GCC) 9.3.1 20200408 (Red Hat 9.3.1-2) , clang version 9.0.1 (Fedora 9.0.1-4.fc31) 28 4.27 fedora:32 : Ok gcc (GCC) 10.3.1 20210422 (Red Hat 10.3.1-1) , clang version 10.0.1 (Fedora 10.0.1-3.fc32) 29 4.38 fedora:33 : Ok gcc (GCC) 10.3.1 20210422 (Red Hat 10.3.1-1) , clang version 11.0.0 (Fedora 11.0.0-3.fc33) 30 4.47 fedora:34 : Ok gcc (GCC) 11.2.1 20210728 (Red Hat 11.2.1-1) , clang version 12.0.1 (Fedora 12.0.1-1.fc34) 31 4.37 fedora:35 : Ok gcc (GCC) 11.2.1 20210728 (Red Hat 11.2.1-1) , clang version 13.0.0 (Fedora 13.0.0~rc1-1.fc35) 32 4.37 fedora:rawhide : Ok gcc (GCC) 11.2.1 20210728 (Red Hat 11.2.1-1) , clang version 12.0.1 (Fedora 12.0.1-2.fc35) 33 4.08 gentoo-stage3:latest : Ok gcc (Gentoo 10.3.0 p1) 10.3.0 34 4.07 mageia:6 : Ok gcc (Mageia 5.5.0-1.mga6) 5.5.0 , clang version 3.9.1 (tags/RELEASE_391/final) 35 4.78 mageia:7 : Ok gcc (Mageia 8.4.0-1.mga7) 8.4.0 , clang version 8.0.0 (Mageia 8.0.0-1.mga7) 36 6.48 openmandriva:cooker : Ok gcc (GCC) 11.2.0 20210728 (OpenMandriva) , OpenMandriva 12.0.1-1 clang version 12.0.1 (/builddir/build/BUILD/llvm-project-12.0.1.src/clang 0a7362bac93d0a3bf152ead1b6b3f98c9a9695d5) 37 4.48 opensuse:15.0 : Ok gcc (SUSE Linux) 7.4.1 20190905 [gcc-7-branch revision 275407] , clang version 5.0.1 (tags/RELEASE_501/final 312548) 38 4.08 opensuse:15.1 : Ok gcc (SUSE Linux) 7.5.0 , clang version 7.0.1 (tags/RELEASE_701/final 349238) 39 3.87 opensuse:15.2 : Ok gcc (SUSE Linux) 7.5.0 , clang version 9.0.1 40 3.78 opensuse:15.3 : Ok gcc (SUSE Linux) 7.5.0 , clang version 11.0.1 41 4.38 opensuse:tumbleweed : Ok gcc (SUSE Linux) 11.1.1 20210721 [revision 076930b9690ac3564638636f6b13bbb6bc608aea] , clang version 12.0.1 42 3.87 oraclelinux:8 : Ok gcc (GCC) 8.4.1 20200928 (Red Hat 8.4.1-1.0.1) , clang version 11.0.0 (Red Hat 11.0.0-1.0.1.module+el8.4.0+20046+39fed697) 43 3.87 rockylinux:8 : Ok gcc (GCC) 8.4.1 20200928 (Red Hat 8.4.1-1) , clang version 11.0.0 (Red Hat 11.0.0-1.module+el8.4.0+412+05cf643f) 44 3.97 ubuntu:16.04 : Ok gcc (Ubuntu 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609 , clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final) 45 4.37 ubuntu:18.04 : Ok gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 , clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final) 46 4.87 ubuntu:20.04 : Ok gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0 , clang version 10.0.0-4ubuntu1 47 4.47 ubuntu:20.10 : Ok gcc (Ubuntu 10.3.0-1ubuntu1~20.10) 10.3.0 , Ubuntu clang version 11.0.0-2 48 4.27 ubuntu:21.04 : Ok gcc (Ubuntu 10.3.0-1ubuntu1) 10.3.0 , Ubuntu clang version 12.0.0-3ubuntu1~21.04.1 49 4.37 ubuntu:21.10 : Ok gcc (Ubuntu 11.2.0-1ubuntu2) 11.2.0 , Ubuntu clang version 12.0.1-1 $ ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: ANNOUNCE: pahole v1.22 (Multithreaded DWARF Loading, detached BTF encoding) 2021-08-23 21:25 ANNOUNCE: pahole v1.22 (Multithreaded DWARF Loading, detached BTF encoding) Arnaldo Carvalho de Melo @ 2021-08-23 21:55 ` Arnaldo Carvalho de Melo 2021-12-08 13:54 ` ANNOUNCE: pahole v1.23 (BTF tags and alignment inference) Arnaldo Carvalho de Melo 1 sibling, 0 replies; 15+ messages in thread From: Arnaldo Carvalho de Melo @ 2021-08-23 21:55 UTC (permalink / raw) To: dwarves Cc: Linux Kernel Mailing List, bpf, Jiri Olsa, Jan Engelhardt, Domenico Andreoli, Matthias Schwarzott, Mark Wieelard, Andrii Nakryiko, Deepak Kumar Mishra, Luca Boccassi, Martin KaFai Lau, Sevan Janiyan, Shuyi Cheng Em Mon, Aug 23, 2021 at 06:25:57PM -0300, Arnaldo Carvalho de Melo escreveu: > Hi, > > The v1.22 release of pahole and its friends is out, this time > the main new features are the ability to encode BTF to a > separate file and Multithreaded DWARF loading. > > Lots of cleanups and improvements resulted from preparing for > multithreading. Please see the changes-1.22 file in the source tree and > at the end of this message for a detailed list of improvements. > > Next step is to multithread BTF encoding, but even without that > the time taken tp encode the kernel BTF information now is slashed by > over 50%. The before/after 'perf stat' output for each of the improvements > can be found in the project git commit log messages. > > The non-cross build set of containers used to test build the > Linux perf tools is now being used to make sure pahole doesn't build > regresses. > > Thanks as well to Andrii for putting in place a CI job for pahole > at https://github.com/libbpf/libbpf/actions/workflows/pahole.yml. > > Main git repo: > > git://git.kernel.org/pub/scm/devel/pahole/pahole.git > > Mirror git repo: > > https://github.com/acmel/dwarves.git > > tarball + gpg signature: > > https://fedorapeople.org/~acme/dwarves/dwarves-1.21.tar.xz > https://fedorapeople.org/~acme/dwarves/dwarves-1.21.tar.bz2 > https://fedorapeople.org/~acme/dwarves/dwarves-1.21.tar.sign Oh well, really at: https://fedorapeople.org/~acme/dwarves/dwarves-1.22.tar.xz https://fedorapeople.org/~acme/dwarves/dwarves-1.22.tar.bz2 https://fedorapeople.org/~acme/dwarves/dwarves-1.22.tar.sign :-) > Thanks a lot to all the contributors and distro packagers, you're on the > CC list, I appreciate a lot the work you put into these tools, > > Best Regards, > > - Arnaldo > > pahole: > > - Allow encoding BTF to a separate BTF file (detached) instead of to a new > ".BTF" ELF section in the file being encoded (vmlinux usually). > > - Introduce -j/--jobs option to specify the number of threads to use. Without > arguments means one thread per CPU. So far used for the DWARF loader, will > be used as well for the BTF encoder. > > - Show all different types with the same name, not just the first one found. > > - Introduce sorted type output (--sort), needed with multithreaded DWARF loading, > to use with things like 'btfdiff' that expects the output from DWARF and BTF > types to be comparable using 'diff'. > > - Stop assuming that reading from stdin means pretty printing as this broke > pre-existing scripts, introduce a explicit --prettify command line option. > > - Improve type resolution for the --header command line option. > > - Disable incomplete CTF encoder, this needs to be done using the external > libctf library. > > - Do not consider the ftrace filter when encoding BTF for kernel functions. > > - Add --kabi_prefix to avoid deduplication woes when using _RH_KABI_REPLACE(), > > - Add --with_flexible_array to show just types with flexible arrays. > > DWARF Loader: > > - Multithreaded loading, requires elfutils >= 0.178. > > - Lock calls to non-thread safe elfutils' libdw functions (dwarf_decl_file() > and dwarf_decl_line()) > > - Change hash table size to one that performs better with current typical > vmlinux files. > > - Allow tweaking the hash table size from the command line. > > - Stop allocating memory for strings obtained from libdw, just defer freeing > the Dwfl handler so that references to its strings can be safely kept. > > - Use a frontend cache for the latest lookup result. > > - Allow ignoring some DWARF tags when loading for encoding BTF, as BTF doesn't > have equivalents for things like DW_TAG_inline_expansion and DW_TAG_label. > > - Allow ignoring some DWARF tag attributes, such as DW_AT_alignment, not used > when encoding BTF. > > - Do not query for non-C attributes when loading a C language CU (compilation unit). > > BTF encoder: > > - Preparatory work for multithreaded encoding, the focus for 1.23. > > btfdiff: > > - Support diffing against a detached BTF file, e.g.: 'btfdiff vmlinux vmlinux.btf' > > - Support multithreaded DWARF loading, using the new pahole --sort option to have > the output from both BTF and DWARF sorted and thus comparable via 'diff'. > > Build: > > - Support building with libc libraries lacking either obstacks or argp, such > as Alpine Linux's musl libc. > > - Support systems without getconf() to obtain the data cacheline size, such > as musl libc. > > - Add a buildcmd.sh for test builds, tested using the same set of containers > used for testing the Linux kernel perf tools. > > - Enable selecting building with a shared libdwarves library or statically. > > - Allow to use the libbpf package found in distributions instead of with the > accompanying libbpf git submodule. > > Cleanups: > > - Address lots of compiler warnings accumulated by not using -Wextra, it'll > be added in the next release after allowing not to use it to build libbpf. > > - Address covscan report issues. > > Documentation: > > - Improve the --nr_methods/-m pahole man page entry. > > - Clarify that currently --nr_methods doesn't work together witn -C. > > Tests: > > $ export BUILD_TARBALL=http://192.168.100.2/pahole/dwarves-1.22.tar.xz > $ export BUILD_CMD=buildcmd.sh > $ time dm -X > 1 3.78 almalinux:8 : Ok gcc (GCC) 8.4.1 20200928 (Red Hat 8.4.1-1) , clang version 11.0.0 (Red Hat 11.0.0-1.module_el8.4.0+2107+39fed697) > 2 5.07 alpine:3.12 : Ok gcc (Alpine 9.3.0) 9.3.0 , Alpine clang version 10.0.0 (https://gitlab.alpinelinux.org/alpine/aports.git 7445adce501f8473efdb93b17b5eaf2f1445ed4c) > 3 5.48 alpine:3.13 : Ok gcc (Alpine 10.2.1_pre1) 10.2.1 20201203 , Alpine clang version 10.0.1 > 4 5.68 alpine:3.14 : Ok gcc (Alpine 10.3.1_git20210424) 10.3.1 20210424 , Alpine clang version 11.1.0 > 5 5.99 alpine:edge : Ok gcc (Alpine 10.3.1_git20210625) 10.3.1 20210625 , Alpine clang version 11.1.0 > 6 4.27 alt:p8 : Ok x86_64-alt-linux-gcc (GCC) 5.3.1 20151207 (ALT p8 5.3.1-alt3.M80P.1) , clang version 3.8.0 (tags/RELEASE_380/final) > 7 4.27 alt:p9 : Ok x86_64-alt-linux-gcc (GCC) 8.4.1 20200305 (ALT p9 8.4.1-alt0.p9.1) , clang version 10.0.0 > 8 5.07 alt:sisyphus : Ok x86_64-alt-linux-gcc (GCC) 10.2.1 20210313 (ALT Sisyphus 10.2.1-alt3) , clang version 10.0.1 > 9 4.67 amazonlinux:1 : Ok gcc (GCC) 7.2.1 20170915 (Red Hat 7.2.1-2) , clang version 3.6.2 (tags/RELEASE_362/final) > 10 4.27 amazonlinux:2 : Ok gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-13) , clang version 11.1.0 (Amazon Linux 2 11.1.0-1.amzn2.0.2) > 11 4.48 centos:8 : Ok gcc (GCC) 8.4.1 20200928 (Red Hat 8.4.1-1) , clang version 11.0.0 (Red Hat 11.0.0-1.module_el8.4.0+587+5187cac0) > 12 4.48 centos:stream : Ok gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-3) , clang version 12.0.0 (Red Hat 12.0.0-1.module_el8.5.0+840+21214faf) > 13 4.18 clearlinux:latest : Ok gcc (Clear Linux OS for Intel Architecture) 11.2.1 20210816 releases/gcc-11.2.0-71-g4a414ac2a5 , clang version 11.1.0 > 14 4.88 debian:9 : Ok gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 , clang version 3.8.1-24 (tags/RELEASE_381/final) > 15 4.79 debian:10 : Ok gcc (Debian 8.3.0-6) 8.3.0 , clang version 7.0.1-8+deb10u2 (tags/RELEASE_701/final) > 16 4.18 debian:11 : Ok gcc (Debian 10.2.1-6) 10.2.1 20210110 , Debian clang version 11.0.1-2 > 17 4.27 debian:experimental : Ok gcc (Debian 10.2.1-6) 10.2.1 20210110 , Debian clang version 11.0.1-2 > 18 3.77 fedora:22 : Ok gcc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6) , clang version 3.5.0 (tags/RELEASE_350/final) > 19 3.97 fedora:23 : Ok gcc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6) , clang version 3.7.0 (tags/RELEASE_370/final) > 20 4.17 fedora:24 : Ok gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1) , clang version 3.8.1 (tags/RELEASE_381/final) > 21 4.37 fedora:25 : Ok gcc (GCC) 6.4.1 20170727 (Red Hat 6.4.1-1) , clang version 3.9.1 (tags/RELEASE_391/final) > 22 4.48 fedora:26 : Ok gcc (GCC) 7.3.1 20180130 (Red Hat 7.3.1-2) , clang version 4.0.1 (tags/RELEASE_401/final) > 23 4.28 fedora:27 : Ok gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-6) , clang version 5.0.2 (tags/RELEASE_502/final) > 24 4.47 fedora:28 : Ok gcc (GCC) 8.3.1 20190223 (Red Hat 8.3.1-2) , clang version 6.0.1 (tags/RELEASE_601/final) > 25 4.37 fedora:29 : Ok gcc (GCC) 8.3.1 20190223 (Red Hat 8.3.1-2) , clang version 7.0.1 (Fedora 7.0.1-6.fc29) > 26 4.28 fedora:30 : Ok gcc (GCC) 9.3.1 20200408 (Red Hat 9.3.1-2) , clang version 8.0.0 (Fedora 8.0.0-3.fc30) > 27 4.07 fedora:31 : Ok gcc (GCC) 9.3.1 20200408 (Red Hat 9.3.1-2) , clang version 9.0.1 (Fedora 9.0.1-4.fc31) > 28 4.27 fedora:32 : Ok gcc (GCC) 10.3.1 20210422 (Red Hat 10.3.1-1) , clang version 10.0.1 (Fedora 10.0.1-3.fc32) > 29 4.38 fedora:33 : Ok gcc (GCC) 10.3.1 20210422 (Red Hat 10.3.1-1) , clang version 11.0.0 (Fedora 11.0.0-3.fc33) > 30 4.47 fedora:34 : Ok gcc (GCC) 11.2.1 20210728 (Red Hat 11.2.1-1) , clang version 12.0.1 (Fedora 12.0.1-1.fc34) > 31 4.37 fedora:35 : Ok gcc (GCC) 11.2.1 20210728 (Red Hat 11.2.1-1) , clang version 13.0.0 (Fedora 13.0.0~rc1-1.fc35) > 32 4.37 fedora:rawhide : Ok gcc (GCC) 11.2.1 20210728 (Red Hat 11.2.1-1) , clang version 12.0.1 (Fedora 12.0.1-2.fc35) > 33 4.08 gentoo-stage3:latest : Ok gcc (Gentoo 10.3.0 p1) 10.3.0 > 34 4.07 mageia:6 : Ok gcc (Mageia 5.5.0-1.mga6) 5.5.0 , clang version 3.9.1 (tags/RELEASE_391/final) > 35 4.78 mageia:7 : Ok gcc (Mageia 8.4.0-1.mga7) 8.4.0 , clang version 8.0.0 (Mageia 8.0.0-1.mga7) > 36 6.48 openmandriva:cooker : Ok gcc (GCC) 11.2.0 20210728 (OpenMandriva) , OpenMandriva 12.0.1-1 clang version 12.0.1 (/builddir/build/BUILD/llvm-project-12.0.1.src/clang 0a7362bac93d0a3bf152ead1b6b3f98c9a9695d5) > 37 4.48 opensuse:15.0 : Ok gcc (SUSE Linux) 7.4.1 20190905 [gcc-7-branch revision 275407] , clang version 5.0.1 (tags/RELEASE_501/final 312548) > 38 4.08 opensuse:15.1 : Ok gcc (SUSE Linux) 7.5.0 , clang version 7.0.1 (tags/RELEASE_701/final 349238) > 39 3.87 opensuse:15.2 : Ok gcc (SUSE Linux) 7.5.0 , clang version 9.0.1 > 40 3.78 opensuse:15.3 : Ok gcc (SUSE Linux) 7.5.0 , clang version 11.0.1 > 41 4.38 opensuse:tumbleweed : Ok gcc (SUSE Linux) 11.1.1 20210721 [revision 076930b9690ac3564638636f6b13bbb6bc608aea] , clang version 12.0.1 > 42 3.87 oraclelinux:8 : Ok gcc (GCC) 8.4.1 20200928 (Red Hat 8.4.1-1.0.1) , clang version 11.0.0 (Red Hat 11.0.0-1.0.1.module+el8.4.0+20046+39fed697) > 43 3.87 rockylinux:8 : Ok gcc (GCC) 8.4.1 20200928 (Red Hat 8.4.1-1) , clang version 11.0.0 (Red Hat 11.0.0-1.module+el8.4.0+412+05cf643f) > 44 3.97 ubuntu:16.04 : Ok gcc (Ubuntu 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609 , clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final) > 45 4.37 ubuntu:18.04 : Ok gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 , clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final) > 46 4.87 ubuntu:20.04 : Ok gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0 , clang version 10.0.0-4ubuntu1 > 47 4.47 ubuntu:20.10 : Ok gcc (Ubuntu 10.3.0-1ubuntu1~20.10) 10.3.0 , Ubuntu clang version 11.0.0-2 > 48 4.27 ubuntu:21.04 : Ok gcc (Ubuntu 10.3.0-1ubuntu1) 10.3.0 , Ubuntu clang version 12.0.0-3ubuntu1~21.04.1 > 49 4.37 ubuntu:21.10 : Ok gcc (Ubuntu 11.2.0-1ubuntu2) 11.2.0 , Ubuntu clang version 12.0.1-1 > > $ -- - Arnaldo ^ permalink raw reply [flat|nested] 15+ messages in thread
* ANNOUNCE: pahole v1.23 (BTF tags and alignment inference) 2021-08-23 21:25 ANNOUNCE: pahole v1.22 (Multithreaded DWARF Loading, detached BTF encoding) Arnaldo Carvalho de Melo 2021-08-23 21:55 ` Arnaldo Carvalho de Melo @ 2021-12-08 13:54 ` Arnaldo Carvalho de Melo 2021-12-08 14:26 ` Jan Engelhardt ` (3 more replies) 1 sibling, 4 replies; 15+ messages in thread From: Arnaldo Carvalho de Melo @ 2021-12-08 13:54 UTC (permalink / raw) To: dwarves Cc: Linux Kernel Mailing List, bpf, Jiri Olsa, Jan Engelhardt, Domenico Andreoli, Matthias Schwarzott, Yonghong Song, Douglas RAILLARD, Ilya Leoshkevich, Matteo Croce Hi, The v1.23 release of pahole and its friends is out, this time the main new features are the ability to encode BTF tags, to carry attributes to the kernel BPF verifier for further checks and the inference of struct member unnatural alignment (__attribute__(__aligned__(N))) to help in generating compileable headers matching the original type layout from BTF data. Main git repo: git://git.kernel.org/pub/scm/devel/pahole/pahole.git Mirror git repo: https://github.com/acmel/dwarves.git tarball + gpg signature: https://fedorapeople.org/~acme/dwarves/dwarves-1.23.tar.xz https://fedorapeople.org/~acme/dwarves/dwarves-1.23.tar.bz2 https://fedorapeople.org/~acme/dwarves/dwarves-1.23.tar.sign Thanks a lot to all the contributors and distro packagers, you're on the CC list, I appreciate a lot the work you put into these tools, Best Regards, - Arnaldo DWARF loader: - Read DW_TAG_LLVM_annotation tags, associating it with variables, functions, types. So far this is only being used by the BTF encoder, but the pretty printer should use this as well in a future release, printing these attributes when available. - Initial support for DW_TAG_skeleton_unit, so far just suggest looking up a matching .dwo file to be used instead. Automagically doing this is in the plans for a future release. - Fix heap overflow when accessing variable specification. BTF encoder: - Support the new BTF type tag attribute, encoding DW_TAG_LLVM_annotation DWARF tags as BTF_KIND_TYPE_TAG and BTF_KIND_DECL_TAG. This allows __attribute__((btf_type_tag("tag1"))) to be used for variables, functions, typedefs, so that contextual information can be stored in BTF and used by the kernel BPF verifier for more checks. The --skip_encoding_btf_type_tag option can be used to suppress this. - Fix handling of percpu symbols on s390. BTF loader: - Use cacheline size to infer alignment. btfdiff: - Now that the BTF loader infers struct member alingment, and as that is just an heuristic, suppress printing the alignment when pretty printing from BTF info like is done when printing from DWARF. pahole: - Add --skip_missing so that we don't stop when not finding one of the types passed to -C. Pretty printer: - Fix __attribute__((__aligned__(N)) printing alignment for struct members. - Fix nested __attribute__(__aligned__(N)) struct printing order, so that rebuilding from the printed source circles back to the original source code alignment semantics. Build: - No need to download libbpf source when using the system library (libbpf-devel). - Make python optional ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: ANNOUNCE: pahole v1.23 (BTF tags and alignment inference) 2021-12-08 13:54 ` ANNOUNCE: pahole v1.23 (BTF tags and alignment inference) Arnaldo Carvalho de Melo @ 2021-12-08 14:26 ` Jan Engelhardt 2021-12-08 18:35 ` Arnaldo Carvalho de Melo 2021-12-14 21:56 ` Nathan Chancellor ` (2 subsequent siblings) 3 siblings, 1 reply; 15+ messages in thread From: Jan Engelhardt @ 2021-12-08 14:26 UTC (permalink / raw) To: Arnaldo Carvalho de Melo Cc: dwarves, Linux Kernel Mailing List, bpf, Jiri Olsa, Domenico Andreoli, Matthias Schwarzott, Yonghong Song, Douglas RAILLARD, Ilya Leoshkevich, Matteo Croce On Wednesday 2021-12-08 14:54, Arnaldo Carvalho de Melo wrote: > > The v1.23 release of pahole and its friends is out, this time >the main new features are the ability to encode BTF tags, to carry [ 7s] /home/abuild/rpmbuild/BUILD/dwarves-1.23/btf_encoder.c:145:10: error: 'BTF_KIND_DECL_TAG' undeclared here (not in a function); did you mean 'BTF_KIND_FLOAT'? libbpf-0.5.0 is present, since CMakeLists.txt checked for >= 0.4.0. The 1.23 tag is missing from git. Is git://git.kernel.org/pub/scm/devel/pahole/pahole out of date? (Last commit from October 2021) ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: ANNOUNCE: pahole v1.23 (BTF tags and alignment inference) 2021-12-08 14:26 ` Jan Engelhardt @ 2021-12-08 18:35 ` Arnaldo Carvalho de Melo 2021-12-08 18:37 ` Arnaldo Carvalho de Melo 2021-12-08 19:11 ` Jan Engelhardt 0 siblings, 2 replies; 15+ messages in thread From: Arnaldo Carvalho de Melo @ 2021-12-08 18:35 UTC (permalink / raw) To: Jan Engelhardt Cc: dwarves, Linux Kernel Mailing List, bpf, Jiri Olsa, Domenico Andreoli, Matthias Schwarzott, Yonghong Song, Douglas RAILLARD, Ilya Leoshkevich, Matteo Croce Em Wed, Dec 08, 2021 at 03:26:31PM +0100, Jan Engelhardt escreveu: > > On Wednesday 2021-12-08 14:54, Arnaldo Carvalho de Melo wrote: > > > > The v1.23 release of pahole and its friends is out, this time > >the main new features are the ability to encode BTF tags, to carry > > [ 7s] /home/abuild/rpmbuild/BUILD/dwarves-1.23/btf_encoder.c:145:10: error: 'BTF_KIND_DECL_TAG' undeclared here (not in a function); did you mean 'BTF_KIND_FLOAT'? > > libbpf-0.5.0 is present, since CMakeLists.txt checked for >= 0.4.0. My fault, knowing the flux that libbpf is in getting to 1.0 I should have retested with the perf tools container based tests. Can you think about some fix for that? Lemme see if BTF_KIND_DECL_TAG is a define or an enum... > The 1.23 tag is missing from git. pushed out, thanks for pointing it out. > Is git://git.kernel.org/pub/scm/devel/pahole/pahole out of date? (Last commit > from October 2021) -- - Arnaldo ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: ANNOUNCE: pahole v1.23 (BTF tags and alignment inference) 2021-12-08 18:35 ` Arnaldo Carvalho de Melo @ 2021-12-08 18:37 ` Arnaldo Carvalho de Melo 2021-12-08 18:49 ` Andrii Nakryiko 2021-12-08 19:11 ` Jan Engelhardt 1 sibling, 1 reply; 15+ messages in thread From: Arnaldo Carvalho de Melo @ 2021-12-08 18:37 UTC (permalink / raw) To: Jan Engelhardt, Andrii Nakryiko Cc: dwarves, Linux Kernel Mailing List, bpf, Jiri Olsa, Domenico Andreoli, Matthias Schwarzott, Yonghong Song, Douglas RAILLARD, Ilya Leoshkevich, Matteo Croce Em Wed, Dec 08, 2021 at 03:35:36PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Wed, Dec 08, 2021 at 03:26:31PM +0100, Jan Engelhardt escreveu: > > On Wednesday 2021-12-08 14:54, Arnaldo Carvalho de Melo wrote: > > > The v1.23 release of pahole and its friends is out, this time > > >the main new features are the ability to encode BTF tags, to carry > > > > [ 7s] /home/abuild/rpmbuild/BUILD/dwarves-1.23/btf_encoder.c:145:10: error: 'BTF_KIND_DECL_TAG' undeclared here (not in a function); did you mean 'BTF_KIND_FLOAT'? > > libbpf-0.5.0 is present, since CMakeLists.txt checked for >= 0.4.0. > My fault, knowing the flux that libbpf is in getting to 1.0 I should > have retested with the perf tools container based tests. > Can you think about some fix for that? Lemme see if BTF_KIND_DECL_TAG is > a define or an enum... enum { BTF_KIND_UNKN = 0, /* Unknown */ BTF_KIND_INT = 1, /* Integer */ BTF_KIND_PTR = 2, /* Pointer */ BTF_KIND_ARRAY = 3, /* Array */ BTF_KIND_STRUCT = 4, /* Struct */ BTF_KIND_UNION = 5, /* Union */ BTF_KIND_ENUM = 6, /* Enumeration */ BTF_KIND_FWD = 7, /* Forward */ BTF_KIND_TYPEDEF = 8, /* Typedef */ BTF_KIND_VOLATILE = 9, /* Volatile */ BTF_KIND_CONST = 10, /* Const */ BTF_KIND_RESTRICT = 11, /* Restrict */ BTF_KIND_FUNC = 12, /* Function */ BTF_KIND_FUNC_PROTO = 13, /* Function Proto */ BTF_KIND_VAR = 14, /* Variable */ BTF_KIND_DATASEC = 15, /* Section */ BTF_KIND_FLOAT = 16, /* Floating point */ BTF_KIND_DECL_TAG = 17, /* Decl Tag */ BTF_KIND_TYPE_TAG = 18, /* Type Tag */ NR_BTF_KINDS, BTF_KIND_MAX = NR_BTF_KINDS - 1, }; Do you guys have any plans on updating libbpf? - Arnaldo ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: ANNOUNCE: pahole v1.23 (BTF tags and alignment inference) 2021-12-08 18:37 ` Arnaldo Carvalho de Melo @ 2021-12-08 18:49 ` Andrii Nakryiko 0 siblings, 0 replies; 15+ messages in thread From: Andrii Nakryiko @ 2021-12-08 18:49 UTC (permalink / raw) To: Arnaldo Carvalho de Melo Cc: Jan Engelhardt, Andrii Nakryiko, dwarves, Linux Kernel Mailing List, bpf, Jiri Olsa, Domenico Andreoli, Matthias Schwarzott, Yonghong Song, Douglas RAILLARD, Ilya Leoshkevich, Matteo Croce On Wed, Dec 8, 2021 at 10:37 AM Arnaldo Carvalho de Melo <acme@kernel.org> wrote: > > Em Wed, Dec 08, 2021 at 03:35:36PM -0300, Arnaldo Carvalho de Melo escreveu: > > Em Wed, Dec 08, 2021 at 03:26:31PM +0100, Jan Engelhardt escreveu: > > > On Wednesday 2021-12-08 14:54, Arnaldo Carvalho de Melo wrote: > > > > The v1.23 release of pahole and its friends is out, this time > > > >the main new features are the ability to encode BTF tags, to carry > > > > > > [ 7s] /home/abuild/rpmbuild/BUILD/dwarves-1.23/btf_encoder.c:145:10: error: 'BTF_KIND_DECL_TAG' undeclared here (not in a function); did you mean 'BTF_KIND_FLOAT'? > > > > libbpf-0.5.0 is present, since CMakeLists.txt checked for >= 0.4.0. > > > My fault, knowing the flux that libbpf is in getting to 1.0 I should > > have retested with the perf tools container based tests. > > > Can you think about some fix for that? Lemme see if BTF_KIND_DECL_TAG is > > a define or an enum... > > enum { > BTF_KIND_UNKN = 0, /* Unknown */ > BTF_KIND_INT = 1, /* Integer */ > BTF_KIND_PTR = 2, /* Pointer */ > BTF_KIND_ARRAY = 3, /* Array */ > BTF_KIND_STRUCT = 4, /* Struct */ > BTF_KIND_UNION = 5, /* Union */ > BTF_KIND_ENUM = 6, /* Enumeration */ > BTF_KIND_FWD = 7, /* Forward */ > BTF_KIND_TYPEDEF = 8, /* Typedef */ > BTF_KIND_VOLATILE = 9, /* Volatile */ > BTF_KIND_CONST = 10, /* Const */ > BTF_KIND_RESTRICT = 11, /* Restrict */ > BTF_KIND_FUNC = 12, /* Function */ > BTF_KIND_FUNC_PROTO = 13, /* Function Proto */ > BTF_KIND_VAR = 14, /* Variable */ > BTF_KIND_DATASEC = 15, /* Section */ > BTF_KIND_FLOAT = 16, /* Floating point */ > BTF_KIND_DECL_TAG = 17, /* Decl Tag */ > BTF_KIND_TYPE_TAG = 18, /* Type Tag */ > > NR_BTF_KINDS, > BTF_KIND_MAX = NR_BTF_KINDS - 1, > }; > > Do you guys have any plans on updating libbpf? > In what sense? It's already updated and knows about all those new KINDS ([0]) [0] https://github.com/libbpf/libbpf/blob/3ef05a585efd47abf4dc92265430d0248d7f388a/src/btf.c#L302 > - Arnaldo ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: ANNOUNCE: pahole v1.23 (BTF tags and alignment inference) 2021-12-08 18:35 ` Arnaldo Carvalho de Melo 2021-12-08 18:37 ` Arnaldo Carvalho de Melo @ 2021-12-08 19:11 ` Jan Engelhardt 2021-12-09 22:09 ` Yonghong Song 1 sibling, 1 reply; 15+ messages in thread From: Jan Engelhardt @ 2021-12-08 19:11 UTC (permalink / raw) To: Arnaldo Carvalho de Melo Cc: dwarves, Linux Kernel Mailing List, bpf, Jiri Olsa, Domenico Andreoli, Matthias Schwarzott, Yonghong Song, Douglas RAILLARD, Ilya Leoshkevich, Matteo Croce On Wednesday 2021-12-08 19:35, Arnaldo Carvalho de Melo wrote: >Em Wed, Dec 08, 2021 at 03:26:31PM +0100, Jan Engelhardt escreveu: >> >> On Wednesday 2021-12-08 14:54, Arnaldo Carvalho de Melo wrote: >> > >> > The v1.23 release of pahole and its friends is out, this time >> >the main new features are the ability to encode BTF tags, to carry >> >> [ 7s] /home/abuild/rpmbuild/BUILD/dwarves-1.23/btf_encoder.c:145:10: error: 'BTF_KIND_DECL_TAG' undeclared here (not in a function); did you mean 'BTF_KIND_FLOAT'? >> >> libbpf-0.5.0 is present, since CMakeLists.txt checked for >= 0.4.0. > >My fault, knowing the flux that libbpf is in getting to 1.0 I should >have retested with the perf tools container based tests. > >Can you think about some fix for that? Lemme see if BTF_KIND_DECL_TAG is >a define or an enum... Just bumping this line pkg_check_modules(LIBBPF REQUIRED libbpf>=0.4.0) to the right version would absolutely be sufficient for us. Of course, that requires that the libbpf project itself at least manages to make tags regularly. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: ANNOUNCE: pahole v1.23 (BTF tags and alignment inference) 2021-12-08 19:11 ` Jan Engelhardt @ 2021-12-09 22:09 ` Yonghong Song 2021-12-12 10:03 ` Jan Engelhardt 0 siblings, 1 reply; 15+ messages in thread From: Yonghong Song @ 2021-12-09 22:09 UTC (permalink / raw) To: Jan Engelhardt, Arnaldo Carvalho de Melo Cc: dwarves, Linux Kernel Mailing List, bpf, Jiri Olsa, Domenico Andreoli, Matthias Schwarzott, Douglas RAILLARD, Ilya Leoshkevich, Matteo Croce On 12/8/21 11:11 AM, Jan Engelhardt wrote: > > On Wednesday 2021-12-08 19:35, Arnaldo Carvalho de Melo wrote: > >> Em Wed, Dec 08, 2021 at 03:26:31PM +0100, Jan Engelhardt escreveu: >>> >>> On Wednesday 2021-12-08 14:54, Arnaldo Carvalho de Melo wrote: >>>> >>>> The v1.23 release of pahole and its friends is out, this time >>>> the main new features are the ability to encode BTF tags, to carry >>> >>> [ 7s] /home/abuild/rpmbuild/BUILD/dwarves-1.23/btf_encoder.c:145:10: error: 'BTF_KIND_DECL_TAG' undeclared here (not in a function); did you mean 'BTF_KIND_FLOAT'? >>> >>> libbpf-0.5.0 is present, since CMakeLists.txt checked for >= 0.4.0. >> >> My fault, knowing the flux that libbpf is in getting to 1.0 I should >> have retested with the perf tools container based tests. >> >> Can you think about some fix for that? Lemme see if BTF_KIND_DECL_TAG is >> a define or an enum... > > Just bumping this line > > pkg_check_modules(LIBBPF REQUIRED libbpf>=0.4.0) > > to the right version would absolutely be sufficient for us. Of course, that > requires that the libbpf project itself at least manages to make tags > regularly. Change above version 0.4.0 to 0.6.0 should work as libbpf 0.6.0 contains all the changes related to BTF_KIND_{TYPE,DECL}_TAGs. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: ANNOUNCE: pahole v1.23 (BTF tags and alignment inference) 2021-12-09 22:09 ` Yonghong Song @ 2021-12-12 10:03 ` Jan Engelhardt 0 siblings, 0 replies; 15+ messages in thread From: Jan Engelhardt @ 2021-12-12 10:03 UTC (permalink / raw) To: Yonghong Song Cc: Arnaldo Carvalho de Melo, dwarves, Linux Kernel Mailing List, bpf, Jiri Olsa, Domenico Andreoli, Matthias Schwarzott, Douglas RAILLARD, Ilya Leoshkevich, Matteo Croce On Thursday 2021-12-09 23:09, Yonghong Song wrote: >> >> Just bumping this line >> >> pkg_check_modules(LIBBPF REQUIRED libbpf>=0.4.0) >> >> to the right version would absolutely be sufficient for us. Of course, that >> requires that the libbpf project itself at least manages to make tags >> regularly. > > Change above version 0.4.0 to 0.6.0 should work as libbpf 0.6.0 contains > all the changes related to BTF_KIND_{TYPE,DECL}_TAGs. Oh well, it does not. /usr/include/bpf/btf.h makes use of BTF_KIND_{TYPE,DECL}_TAGs, but if /usr/include/linux/btf.h does not have it (yet), compilation of libbpf-using components fails left and right unfortunately despite libbpf itself succeeding in compilation. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: ANNOUNCE: pahole v1.23 (BTF tags and alignment inference) 2021-12-08 13:54 ` ANNOUNCE: pahole v1.23 (BTF tags and alignment inference) Arnaldo Carvalho de Melo 2021-12-08 14:26 ` Jan Engelhardt @ 2021-12-14 21:56 ` Nathan Chancellor 2021-12-15 14:56 ` Arnaldo Carvalho de Melo 2021-12-17 19:12 ` Arnaldo Carvalho de Melo 2024-02-28 19:39 ` ANNOUNCE: pahole v1.26 (more holes, --bpf_features, --contains_enum) Arnaldo Carvalho de Melo 2024-05-16 9:36 ` Domenico Andreoli 3 siblings, 2 replies; 15+ messages in thread From: Nathan Chancellor @ 2021-12-14 21:56 UTC (permalink / raw) To: Arnaldo Carvalho de Melo Cc: dwarves, Linux Kernel Mailing List, bpf, Jiri Olsa, Jan Engelhardt, Domenico Andreoli, Matthias Schwarzott, Yonghong Song, Douglas RAILLARD, Ilya Leoshkevich, Matteo Croce Hi Arnaldo, On Wed, Dec 08, 2021 at 10:54:56AM -0300, Arnaldo Carvalho de Melo wrote: > - Initial support for DW_TAG_skeleton_unit, so far just suggest looking up a > matching .dwo file to be used instead. Automagically doing this is in the > plans for a future release. This change [1] appears to break building on older distributions for me, which I use in containers for access to older versions of GCC. I see the error with Debian Stretch and Ubuntu Xenial, which have an older libelf-dev. Is this expected? I don't mind sticking with 1.22 for those, I just want to be sure! /tmp/dwarves-1.23/dwarf_loader.c: In function 'die__process': /tmp/dwarves-1.23/dwarf_loader.c:2529:13: error: 'DW_TAG_skeleton_unit' undeclared (first use in this function) if (tag == DW_TAG_skeleton_unit) { ^ [1]: https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit/?id=0135ccd632796ab3aff65b7c99b374c4682c2bcf Cheers, Nathan ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: ANNOUNCE: pahole v1.23 (BTF tags and alignment inference) 2021-12-14 21:56 ` Nathan Chancellor @ 2021-12-15 14:56 ` Arnaldo Carvalho de Melo 2021-12-17 19:12 ` Arnaldo Carvalho de Melo 1 sibling, 0 replies; 15+ messages in thread From: Arnaldo Carvalho de Melo @ 2021-12-15 14:56 UTC (permalink / raw) To: Nathan Chancellor Cc: dwarves, Linux Kernel Mailing List, bpf, Jiri Olsa, Jan Engelhardt, Domenico Andreoli, Matthias Schwarzott, Yonghong Song, Douglas RAILLARD, Ilya Leoshkevich, Matteo Croce Em Tue, Dec 14, 2021 at 02:56:16PM -0700, Nathan Chancellor escreveu: > Hi Arnaldo, > > On Wed, Dec 08, 2021 at 10:54:56AM -0300, Arnaldo Carvalho de Melo wrote: > > - Initial support for DW_TAG_skeleton_unit, so far just suggest looking up a > > matching .dwo file to be used instead. Automagically doing this is in the > > plans for a future release. > > This change [1] appears to break building on older distributions for me, > which I use in containers for access to older versions of GCC. I see the > error with Debian Stretch and Ubuntu Xenial, which have an older > libelf-dev. Is this expected? I don't mind sticking with 1.22 for > those, I just want to be sure! Nope, not expected, I'll reproduce here, fix and push, thanks for the report. - Arnaldo > /tmp/dwarves-1.23/dwarf_loader.c: In function 'die__process': > /tmp/dwarves-1.23/dwarf_loader.c:2529:13: error: 'DW_TAG_skeleton_unit' undeclared (first use in this function) > if (tag == DW_TAG_skeleton_unit) { > ^ > > [1]: https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit/?id=0135ccd632796ab3aff65b7c99b374c4682c2bcf > > Cheers, > Nathan -- - Arnaldo ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: ANNOUNCE: pahole v1.23 (BTF tags and alignment inference) 2021-12-14 21:56 ` Nathan Chancellor 2021-12-15 14:56 ` Arnaldo Carvalho de Melo @ 2021-12-17 19:12 ` Arnaldo Carvalho de Melo 1 sibling, 0 replies; 15+ messages in thread From: Arnaldo Carvalho de Melo @ 2021-12-17 19:12 UTC (permalink / raw) To: Nathan Chancellor Cc: dwarves, Linux Kernel Mailing List, bpf, Jiri Olsa, Jan Engelhardt, Domenico Andreoli, Matthias Schwarzott, Yonghong Song, Douglas RAILLARD, Ilya Leoshkevich, Matteo Croce Em Tue, Dec 14, 2021 at 02:56:16PM -0700, Nathan Chancellor escreveu: > Hi Arnaldo, > > On Wed, Dec 08, 2021 at 10:54:56AM -0300, Arnaldo Carvalho de Melo wrote: > > - Initial support for DW_TAG_skeleton_unit, so far just suggest looking up a > > matching .dwo file to be used instead. Automagically doing this is in the > > plans for a future release. > > This change [1] appears to break building on older distributions for me, > which I use in containers for access to older versions of GCC. I see the > error with Debian Stretch and Ubuntu Xenial, which have an older > libelf-dev. Is this expected? I don't mind sticking with 1.22 for > those, I just want to be sure! > > /tmp/dwarves-1.23/dwarf_loader.c: In function 'die__process': > /tmp/dwarves-1.23/dwarf_loader.c:2529:13: error: 'DW_TAG_skeleton_unit' undeclared (first use in this function) > if (tag == DW_TAG_skeleton_unit) { > ^ > > [1]: https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit/?id=0135ccd632796ab3aff65b7c99b374c4682c2bcf > with the following patch: commit 2f7d61b2bfb59427926867c886595ff28dd50607 Author: Arnaldo Carvalho de Melo <acme@redhat.com> Date: Fri Dec 17 15:50:17 2021 -0300 core: Define DW_TAG_skeleton_unit if not available on current dwarf.h We use this in both the dwarf_loader.c and in fprintf.c, so define it in dwarves.h that is included in both. Reported-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/all/YbkTAPn3EEu6BUYR@archlinux-ax161 Cc: Domenico Andreoli <domenico.andreoli@linux.com> Cc: Douglas RAILLARD <douglas.raillard@arm.com> Cc: Ilya Leoshkevich <iii@linux.ibm.com> Cc: Jan Engelhardt <jengelh@inai.de> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Matteo Croce <mcroce@microsoft.com> Cc: Matthias Schwarzott <zzam@gentoo.org> Cc: Yonghong Song <yhs@fb.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> diff --git a/dwarves.h b/dwarves.h index 52d162d67456bf12..2132da0ef02b78fd 100644 --- a/dwarves.h +++ b/dwarves.h @@ -1390,4 +1390,8 @@ extern bool no_bitfield_type_recode; extern const char tabs[]; +#ifndef DW_TAG_skeleton_unit +#define DW_TAG_skeleton_unit 0x4a +#endif + #endif /* _DWARVES_H_ */ And using the perf build containers to build with both gcc and clang only a few older distros are failing, I'll make buildcmd.sh, that is in the dwarves repo, to build using the system libbpf-devel (or equivalent) package and have this running after processing patches as I did for 1.22 but forgot to do for 1.23 :-/ - Arnaldo [perfbuilder@five ~]$ export BUILD_TARBALL=http://192.168.100.2/pahole/dwarves-1.24.tar.xz [perfbuilder@five ~]$ export BUILD_CMD=buildcmd.sh [perfbuilder@five ~]$ time dm -X 1 3.67 almalinux:8 : Ok gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-4) , clang version 12.0.1 (Red Hat 12.0.1-4.module_el8.5.0+1025+93159d6c) 2 0.96 alpine:3.4 : FAIL gcc version 5.3.0 (Alpine 5.3.0) 3 0.96 alpine:3.5 : FAIL gcc version 6.2.1 20160822 (Alpine 6.2.1) 4 1.06 alpine:3.6 : FAIL gcc version 6.3.0 (Alpine 6.3.0) 5 1.06 alpine:3.7 : FAIL gcc version 6.4.0 (Alpine 6.4.0) 6 0.96 alpine:3.8 : FAIL gcc version 6.4.0 (Alpine 6.4.0) 7 0.86 alpine:3.9 : FAIL gcc version 8.3.0 (Alpine 8.3.0) 8 1.06 alpine:3.10 : FAIL gcc version 8.3.0 (Alpine 8.3.0) 9 0.76 alpine:3.11 : FAIL gcc version 9.3.0 (Alpine 9.3.0) 10 4.47 alpine:3.12 : Ok gcc (Alpine 9.3.0) 9.3.0 , Alpine clang version 10.0.0 (https://gitlab.alpinelinux.org/alpine/aports.git 7445adce501f8473efdb93b17b5eaf2f1445ed4c) 11 4.87 alpine:3.13 : Ok gcc (Alpine 10.2.1_pre1) 10.2.1 20201203 , Alpine clang version 10.0.1 12 4.87 alpine:3.14 : Ok gcc (Alpine 10.3.1_git20210424) 10.3.1 20210424 , Alpine clang version 11.1.0 13 4.77 alpine:3.15 : Ok gcc (Alpine 10.3.1_git20211027) 10.3.1 20211027 , Alpine clang version 12.0.1 14 5.07 alpine:edge : Ok gcc (Alpine 11.2.1_git20211128) 11.2.1 20211128 , Alpine clang version 12.0.1 15 3.27 alt:p8 : Ok x86_64-alt-linux-gcc (GCC) 5.3.1 20151207 (ALT p8 5.3.1-alt3.M80P.1) , clang version 3.8.0 (tags/RELEASE_380/final) 16 3.66 alt:p9 : Ok x86_64-alt-linux-gcc (GCC) 8.4.1 20200305 (ALT p9 8.4.1-alt0.p9.1) , clang version 10.0.0 17 3.57 alt:p10 : Ok x86_64-alt-linux-gcc (GCC) 10.3.1 20210703 (ALT Sisyphus 10.3.1-alt2) , clang version 11.0.1 18 3.66 alt:sisyphus : Ok x86_64-alt-linux-gcc (GCC) 11.2.1 20210911 (ALT Sisyphus 11.2.1-alt1) , ALT Linux Team clang version 12.0.1 19 3.16 amazonlinux:1 : Ok gcc (GCC) 7.2.1 20170915 (Red Hat 7.2.1-2) , clang version 3.6.2 (tags/RELEASE_362/final) 20 3.26 amazonlinux:2 : Ok gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-13) , clang version 11.1.0 (Amazon Linux 2 11.1.0-1.amzn2.0.2) 21 3.46 centos:8 : Ok gcc (GCC) 8.4.1 20200928 (Red Hat 8.4.1-1) , clang version 11.0.1 (Red Hat 11.0.1-1.module_el8.4.0+966+2995ef20) 22 3.46 centos:stream : Ok gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-3) , clang version 12.0.1 (Red Hat 12.0.1-2.module_el8.6.0+937+1cafe22c) 23 3.57 clearlinux:latest : Ok gcc (Clear Linux OS for Intel Architecture) 11.2.1 20211208 releases/gcc-11.2.0-562-gbd918acae2 , clang version 11.1.0 24 3.77 debian:9 : Ok gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 , clang version 3.8.1-24 (tags/RELEASE_381/final) 25 3.67 debian:10 : Ok gcc (Debian 8.3.0-6) 8.3.0 , clang version 7.0.1-8+deb10u2 (tags/RELEASE_701/final) 26 3.67 debian:11 : Ok gcc (Debian 10.2.1-6) 10.2.1 20210110 , Debian clang version 11.0.1-2 27 3.87 debian:experimental : Ok gcc (Debian 11.2.0-12) 11.2.0 , Debian clang version 13.0.0-9+b1 28 3.16 fedora:22 : Ok gcc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6) , clang version 3.5.0 (tags/RELEASE_350/final) 29 3.46 fedora:23 : Ok gcc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6) , clang version 3.7.0 (tags/RELEASE_370/final) 30 3.47 fedora:24 : Ok gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1) , clang version 3.8.1 (tags/RELEASE_381/final) 31 3.48 fedora:25 : Ok gcc (GCC) 6.4.1 20170727 (Red Hat 6.4.1-1) , clang version 3.9.1 (tags/RELEASE_391/final) 32 3.67 fedora:26 : Ok gcc (GCC) 7.3.1 20180130 (Red Hat 7.3.1-2) , clang version 4.0.1 (tags/RELEASE_401/final) 33 3.46 fedora:27 : Ok gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-6) , clang version 5.0.2 (tags/RELEASE_502/final) 34 3.87 fedora:28 : Ok gcc (GCC) 8.3.1 20190223 (Red Hat 8.3.1-2) , clang version 6.0.1 (tags/RELEASE_601/final) 35 3.87 fedora:29 : Ok gcc (GCC) 8.3.1 20190223 (Red Hat 8.3.1-2) , clang version 7.0.1 (Fedora 7.0.1-6.fc29) 36 3.67 fedora:30 : Ok gcc (GCC) 9.3.1 20200408 (Red Hat 9.3.1-2) , clang version 8.0.0 (Fedora 8.0.0-3.fc30) 37 3.56 fedora:31 : Ok gcc (GCC) 9.3.1 20200408 (Red Hat 9.3.1-2) , clang version 9.0.1 (Fedora 9.0.1-4.fc31) 38 3.76 fedora:32 : Ok gcc (GCC) 10.3.1 20210422 (Red Hat 10.3.1-1) , clang version 10.0.1 (Fedora 10.0.1-3.fc32) 39 3.57 fedora:33 : Ok gcc (GCC) 10.3.1 20210422 (Red Hat 10.3.1-1) , clang version 11.0.0 (Fedora 11.0.0-3.fc33) 40 3.67 fedora:34 : Ok gcc (GCC) 11.2.1 20210728 (Red Hat 11.2.1-1) , clang version 12.0.1 (Fedora 12.0.1-1.fc34) 41 3.87 fedora:35 : Ok gcc (GCC) 11.2.1 20210728 (Red Hat 11.2.1-1) , clang version 13.0.0 (Fedora 13.0.0-3.fc35) 42 3.87 fedora:rawhide : Ok gcc (GCC) 11.2.1 20211203 (Red Hat 11.2.1-7) , clang version 13.0.0 (Fedora 13.0.0-5.fc36) 43 3.97 gentoo-stage3:latest : Ok gcc (Gentoo 11.2.0 p1) 11.2.0 , clang version 13.0.0 44 3.37 mageia:6 : Ok gcc (Mageia 5.5.0-1.mga6) 5.5.0 , clang version 3.9.1 (tags/RELEASE_391/final) 45 3.97 mageia:7 : Ok gcc (Mageia 8.4.0-1.mga7) 8.4.0 , clang version 8.0.0 (Mageia 8.0.0-1.mga7) 46 4.67 openmandriva:cooker : FAIL gcc version 11.2.0 20210728 (OpenMandriva) (GCC) 47 3.97 opensuse:15.0 : Ok gcc (SUSE Linux) 7.4.1 20190905 [gcc-7-branch revision 275407] , clang version 5.0.1 (tags/RELEASE_501/final 312548) 48 3.57 opensuse:15.1 : Ok gcc (SUSE Linux) 7.5.0 , clang version 7.0.1 (tags/RELEASE_701/final 349238) 49 3.46 opensuse:15.2 : Ok gcc (SUSE Linux) 7.5.0 , clang version 9.0.1 50 3.36 opensuse:15.3 : Ok gcc (SUSE Linux) 7.5.0 , clang version 11.0.1 51 3.97 opensuse:tumbleweed : Ok gcc (SUSE Linux) 11.2.1 20210816 [revision 056e324ce46a7924b5cf10f61010cf9dd2ca10e9] , clang version 13.0.0 52 3.57 oraclelinux:8 : Ok gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-4.0.1) , clang version 12.0.1 (Red Hat 12.0.1-4.0.1.module+el8.5.0+20428+2b4ecd47) 53 3.67 rockylinux:8 : Ok gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-4) , clang version 12.0.1 (Red Hat 12.0.1-4.module+el8.5.0+715+58f51d49) 54 3.47 ubuntu:16.04 : Ok gcc (Ubuntu 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609 , clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final) 55 3.67 ubuntu:18.04 : Ok gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 , clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final) 56 3.97 ubuntu:20.04 : Ok gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0 , clang version 10.0.0-4ubuntu1 57 3.87 ubuntu:20.10 : Ok gcc (Ubuntu 10.3.0-1ubuntu1~20.10) 10.3.0 , Ubuntu clang version 11.0.0-2 58 3.57 ubuntu:21.04 : Ok gcc (Ubuntu 10.3.0-1ubuntu1) 10.3.0 , Ubuntu clang version 12.0.0-3ubuntu1~21.04.2 59 3.66 ubuntu:21.10 : Ok gcc (Ubuntu 11.2.0-7ubuntu2) 11.2.0 , Ubuntu clang version 13.0.0-2 60 199.605 real 4m55.822s user 1m16.561s sys 0m17.551s [perfbuilder@five ~]$ ^ permalink raw reply related [flat|nested] 15+ messages in thread
* ANNOUNCE: pahole v1.26 (more holes, --bpf_features, --contains_enum) 2021-12-08 13:54 ` ANNOUNCE: pahole v1.23 (BTF tags and alignment inference) Arnaldo Carvalho de Melo 2021-12-08 14:26 ` Jan Engelhardt 2021-12-14 21:56 ` Nathan Chancellor @ 2024-02-28 19:39 ` Arnaldo Carvalho de Melo 2024-05-16 9:36 ` Domenico Andreoli 3 siblings, 0 replies; 15+ messages in thread From: Arnaldo Carvalho de Melo @ 2024-02-28 19:39 UTC (permalink / raw) To: dwarves Cc: Linux Kernel Mailing List, bpf, Alan Maguire, Andrii Nakryiko, Jiri Olsa, Jan Engelhardt, Domenico Andreoli, Matthias Schwarzott, Viktor Malik, Eduard Zingerman, J B Hi, The v1.26 release of pahole and its friends is out, showing more holes (the ones in contained types) the ability to express the BTF features to encode, to simplify the addition of new BTF features in the Linux kernel build infrastructure, a way to find the enumeration with some enumerator and various fixes. Main git repo: git://git.kernel.org/pub/scm/devel/pahole/pahole.git Mirror git repo: https://github.com/acmel/dwarves.git tarball + gpg signature: https://fedorapeople.org/~acme/dwarves/dwarves-1.26.tar.xz https://fedorapeople.org/~acme/dwarves/dwarves-1.26.tar.bz2 https://fedorapeople.org/~acme/dwarves/dwarves-1.26.tar.sign Thanks a lot to all the contributors and distro packagers, you're on the CC list, I appreciate a lot the work you put into these tools, Best Regards, - Arnaldo pahole: - When expanding types using 'pahole -E' do it for union and struct typedefs and for enums too. E.g: that 'state' field in 'struct module': $ pahole module | head struct module { enum module_state state; /* 0 4 */ /* XXX 4 bytes hole, try to pack */ struct list_head list; /* 8 16 */ char name[56]; /* 24 56 */ /* --- cacheline 1 boundary (64 bytes) was 16 bytes ago --- */ struct module_kobject mkobj; /* 80 96 */ /* --- cacheline 2 boundary (128 bytes) was 48 bytes ago --- */ $ now gets expanded: $ pahole -E module | head struct module { enum module_state { MODULE_STATE_LIVE = 0, MODULE_STATE_COMING = 1, MODULE_STATE_GOING = 2, MODULE_STATE_UNFORMED = 3, } state; /* 0 4 */ /* XXX 4 bytes hole, try to pack */ $ - Print number of holes, bit holes and bit paddings in class member types. Doing this recursively to show how much waste a complex data structure has is something that still needs to be done, there were the low hanging fruits on the path to having that feature. For instance, for 'struct task_struct' in the Linux kernel we get this extra info: --- task_struct.before.c 2024-02-09 11:38:39.249638750 -0300 +++ task_struct.after.c 2024-02-09 16:19:34.221134835 -0300 @@ -29,6 +29,12 @@ /* --- cacheline 2 boundary (128 bytes) --- */ struct sched_entity se; /* 128 256 */ + + /* XXX last struct has 3 holes */ + /* --- cacheline 6 boundary (384 bytes) --- */ struct sched_rt_entity rt; /* 384 48 */ struct sched_dl_entity dl; /* 432 224 */ + + /* XXX last struct has 1 bit hole */ + /* --- cacheline 10 boundary (640 bytes) was 16 bytes ago --- */ const struct sched_class * sched_class; /* 656 8 */ struct rb_node core_node; /* 664 24 */ @@ -100,6 +103,9 @@ /* --- cacheline 35 boundary (2240 bytes) was 16 bytes ago --- */ struct list_head tasks; /* 2256 16 */ struct plist_node pushable_tasks; /* 2272 40 */ + + /* XXX last struct has 1 hole */ + /* --- cacheline 36 boundary (2304 bytes) was 8 bytes ago --- */ struct rb_node pushable_dl_tasks; /* 2312 24 */ struct mm_struct * mm; /* 2336 8 */ @@ -172,6 +178,9 @@ /* XXX last struct has 4 bytes of padding */ struct vtime vtime; /* 2744 48 */ + + /* XXX last struct has 1 hole */ + /* --- cacheline 43 boundary (2752 bytes) was 40 bytes ago --- */ atomic_t tick_dep_mask; /* 2792 4 */ @@ -396,9 +405,12 @@ /* --- cacheline 145 boundary (9280 bytes) --- */ struct thread_struct thread __attribute__((__aligned__(64))); /* 9280 4416 */ + /* XXX last struct has 1 hole, 1 bit hole */ + /* size: 13696, cachelines: 214, members: 262 */ /* sum members: 13518, holes: 21, sum holes: 162 */ /* sum bitfield members: 82 bits, bit holes: 2, sum bit holes: 46 bits */ /* member types with holes: 4, total: 6, bit holes: 2, total: 2 */ /* paddings: 6, sum paddings: 49 */ /* forced alignments: 2, forced holes: 2, sum forced holes: 88 */ }; - Introduce --contains_enumerator=ENUMERATOR_NAME: E.g.: $ pahole --contains_enumerator S_VERSION enum file_time_flags { S_ATIME = 1, S_MTIME = 2, S_CTIME = 4, S_VERSION = 8, } $ The shorter form --contains_enum is also accepted. - Fix pretty printing when using DWARF, where sometimes the class (-C) and a specified "type_enum", may not be present on the same CU, so wait till both are found. Now this example that reads the 'struct perf_event_header' and 'enum perf_event_type' from the DWARF info in ~/bin/perf to pretty print records in the perf.data file works just like when using type info from BTF in ~/bin/perf: $ pahole -F dwarf -V ~/bin/perf \ --header=perf_file_header \ --seek_bytes '$header.data.offset' \ --size_bytes='$header.data.size' \ -C 'perf_event_header(sizeof,type,type_enum=perf_event_type,filter=type==PERF_RECORD_MMAP2)' \ --prettify perf.data --count 1 pahole: sizeof_operator for 'perf_event_header' is 'size' pahole: type member for 'perf_event_header' is 'type' pahole: type enum for 'perf_event_header' is 'perf_event_type' pahole: filter for 'perf_event_header' is 'type==PERF_RECORD_MMAP2' pahole: seek bytes evaluated from --seek_bytes=$header.data.offset is 0x3f0 pahole: size bytes evaluated from --size_bytes=$header.data.size is 0xd10 // type=perf_event_header, offset=0xc20, sizeof=8, real_sizeof=112 { .header = { .type = PERF_RECORD_MMAP2, .misc = 2, .size = 112, }, .pid = 1533617, .tid = 1533617, .start = 94667542700032, .len = 90112, .pgoff = 16384,{ .maj = 0, .min = 33, .ino = 35914923, .ino_generation = 26870, },{ .build_id_size = 0, .__reserved_1 = 0, .__reserved_2 = 0, .build_id = { 33, 0, 0, 0, -85, 4, 36, 2, 0, 0, 0, 0, -10, 104, 0, 0, 0, 0, 0, 0 }, }, .prot = 5, .flags = 2, .filename = "/usr/bin/ls", }, $ DWARF loader: - Add support for DW_TAG_constant, first seen in Go DWARF. - Fix loading DW_TAG_subroutine_type generated by the Go compiler, where it may have a DW_AT_byte_size. Go DWARF. And pretty print it as if it was from C, this helped in writing BPF programs to attach to Go binaries, using uprobes. BTF loader: - Fix loading of 32-bit signed enums. BTF encoder: - Add 'pahole --btf_features' to allow consumers to specify an opt-in set of features they want to use in BTF encoding. Supported features are a comma-separated combination of encode_force Ignore invalid symbols when encoding BTF. var Encode variables using BTF_KIND_VAR in BTF. float Encode floating-point types in BTF. decl_tag Encode declaration tags using BTF_KIND_DECL_TAG. type_tag Encode type tags using BTF_KIND_TYPE_TAG. enum64 Encode enum64 values with BTF_KIND_ENUM64. optimized_func Encode representations of optimized functions with suffixes like ".isra.0" etc consistent_func Avoid encoding inconsistent static functions. These occur when a parameter is optimized out in some CUs and not others, or when the same function name has inconsistent BTF descriptions in different CUs. Specifying "--btf_features=all" is the equivalent to setting all of the above. If pahole does not know about a feature specified in --btf_features it silently ignores it. The --btf_features can either be specified via a single comma-separated list --btf_features=enum64,float ...or via multiple --btf_features values --btf_features=enum64 --btf_features=float These properties allow us to use the --btf_features option in the kernel scripts/pahole_flags.sh script to specify the desired set of BTF features. If a feature named in --btf_features is not present in the version of pahole used, BTF encoding will not complain. This is desired because it means we no longer have to tie new features to a specific pahole version. Use --btf_features_strict to change that behaviour and bail out if one of the requested features isn't present. To see the supported features, use: $ pahole --supported_btf_features encode_force,var,float,decl_tag,type_tag,enum64,optimized_func,consistent_func $ btfdiff: - Parallelize loading BTF and DWARF, speeding up a bit. - Do type expansion to cover "private" types and enumerations. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: ANNOUNCE: pahole v1.26 (more holes, --bpf_features, --contains_enum) 2021-12-08 13:54 ` ANNOUNCE: pahole v1.23 (BTF tags and alignment inference) Arnaldo Carvalho de Melo ` (2 preceding siblings ...) 2024-02-28 19:39 ` ANNOUNCE: pahole v1.26 (more holes, --bpf_features, --contains_enum) Arnaldo Carvalho de Melo @ 2024-05-16 9:36 ` Domenico Andreoli 3 siblings, 0 replies; 15+ messages in thread From: Domenico Andreoli @ 2024-05-16 9:36 UTC (permalink / raw) To: Arnaldo Carvalho de Melo Cc: dwarves, Linux Kernel Mailing List, bpf, Alan Maguire, Andrii Nakryiko, Jiri Olsa, Jan Engelhardt, Matthias Schwarzott, Viktor Malik, Eduard Zingerman, J B [-- Attachment #1: Type: text/plain, Size: 1170 bytes --] On Wed, Feb 28, 2024 at 04:39:21PM -0300, Arnaldo Carvalho de Melo wrote: > Hi, > > The v1.26 release of pahole and its friends is out, showing more > holes (the ones in contained types) the ability to express the BTF > features to encode, to simplify the addition of new BTF features in the > Linux kernel build infrastructure, a way to find the enumeration with > some enumerator and various fixes. > > Main git repo: > > git://git.kernel.org/pub/scm/devel/pahole/pahole.git > > Mirror git repo: > > https://github.com/acmel/dwarves.git > > tarball + gpg signature: > > https://fedorapeople.org/~acme/dwarves/dwarves-1.26.tar.xz > https://fedorapeople.org/~acme/dwarves/dwarves-1.26.tar.bz2 > https://fedorapeople.org/~acme/dwarves/dwarves-1.26.tar.sign Which key do you use to sign this? ^^^^^^^^^^^^^^^^^^^^^ > > Thanks a lot to all the contributors and distro packagers, you're on the > CC list, I appreciate a lot the work you put into these tools, > > Best Regards, -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2024-05-16 9:36 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-08-23 21:25 ANNOUNCE: pahole v1.22 (Multithreaded DWARF Loading, detached BTF encoding) Arnaldo Carvalho de Melo 2021-08-23 21:55 ` Arnaldo Carvalho de Melo 2021-12-08 13:54 ` ANNOUNCE: pahole v1.23 (BTF tags and alignment inference) Arnaldo Carvalho de Melo 2021-12-08 14:26 ` Jan Engelhardt 2021-12-08 18:35 ` Arnaldo Carvalho de Melo 2021-12-08 18:37 ` Arnaldo Carvalho de Melo 2021-12-08 18:49 ` Andrii Nakryiko 2021-12-08 19:11 ` Jan Engelhardt 2021-12-09 22:09 ` Yonghong Song 2021-12-12 10:03 ` Jan Engelhardt 2021-12-14 21:56 ` Nathan Chancellor 2021-12-15 14:56 ` Arnaldo Carvalho de Melo 2021-12-17 19:12 ` Arnaldo Carvalho de Melo 2024-02-28 19:39 ` ANNOUNCE: pahole v1.26 (more holes, --bpf_features, --contains_enum) Arnaldo Carvalho de Melo 2024-05-16 9:36 ` Domenico Andreoli
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).