On Tue, 1 Aug 2023 18:45:49 -0300 Arnaldo Carvalho de Melo <acme@xxxxxxxxxx> wrote: > Em Tue, Aug 01, 2023 at 06:36:49PM +0100, Alan Maguire escreveu: > > On 01/08/2023 02:01, Masami Hiramatsu (Google) wrote: > > > On Mon, 31 Jul 2023 16:45:24 +0100 > > > Alan Maguire <alan.maguire@xxxxxxxxxx> wrote: > > > > > >> On 27/07/2023 02:51, Masami Hiramatsu (Google) wrote: > > >>> On Thu, 27 Jul 2023 09:38:14 +0900 > > >>> Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx> wrote: > > >>> > > >>>>> Yep, BPF generation is more selective about what it emits in 1.25 to > > >>>>> avoid cases where a kernel function signature is ambiguous (multiple > > >>>>> functions of the same name with different signatures) or where it has > > >>>>> unexpected register use. You can observe this via pahole's --verbose > > >>>>> option (a lot of outut is emitted): > > >>>>> > > >>>>> In a built kernel directory (where unstripped vmlinux is present): > > >>>>> $ PAHOLE_FLAGS=$(./scripts/pahole_flags) > > >>>>> $ PAHOLE=/usr/local/bin/pahole > > >>>>> $ pahole --verbose -J $PAHOLE_FLAGS vmlinux > /tmp/pahole.out > > >>>> > > >>>> So this will generate BTF from vmlinux DWARF info. > > >>>> > > >>>>> If you want to investigate why a function has been left out, look for > > >>>>> "skipping" verbose output like this: > > >>>>> > > >>>>> skipping addition of 'access_error'(access_error) due to multiple > > >>>>> inconsistent function prototypes > > >>>>> skipping addition of > > >>>>> 'acpi_ex_convert_to_object_type_string'(acpi_ex_convert_to_object_type_string.isra.0) > > >>>>> due to unexpected register used for parameter > > >>>> > > >>>> Ah, that's nice. Let me try. > > >>> > > >>> $ pahole --version > > >>> v1.23 > > >>> > > >> > > >> shouldn't this be v1.25? Is it possible pahole is picking up the wrong > > >> libdwarves? what does "ldd pahole" say? > > > > > > Here it is. > > > $ ldd pahole > > > linux-vdso.so.1 (0x00007ffd6b1e2000) > > > libdwarves_reorganize.so.1 => /opt/local/pahole/libdwarves_reorganize.so.1 (0x00007f1ddaad9000) > > > libdwarves.so.1 => /opt/local/pahole/libdwarves.so.1 (0x00007f1ddaa72000) > > > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1dda82a000) > > > libdw.so.1 => /usr/local/lib/x86_64-linux-gnu/libdw.so.1 (0x00007f1dda78c000) > > > libelf.so.1 => /usr/local/lib/x86_64-linux-gnu/libelf.so.1 (0x00007f1dda771000) > > > libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f1dda753000) > > > /lib64/ld-linux-x86-64.so.2 (0x00007f1ddaaef000) > > > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f1dda74e000) > > > liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f1dda723000) > > > libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f1dda71e000) > > > > > > Maybe libdwarvers is not related, I could build pahole v1.23 and v1.22 without > > > sync the submodule. > > > > > > I also confirmed the same issue on Ubuntu 22.04's combination, which > > > update pahole from v1.22 to v1.25 recently. (but gcc is still v11.3) > > > > > > gcc-11.3 | clang-16.0 > > > ---------------------------+---------------- > > > v1.22 OK OK > > > (ubuntu) > > > v1.22 OK OK > > > (local) > > > v1.23 NG OK > > > (local) > > > v1.24 NG - > > > (local) > > > v1.25 NG - > > > (ubuntu) > > > v1.25 NG OK > > > (local) > > > > > > So, as far as I checked, there is something wrong between v1.22 and v1.23 > > > which is also related to gcc-11.3. > > > > > > > One thing that is notable about gcc 11 is that I believe it's the first > > gcc release to emit DWARF5 by default. I wonder if it's possible that > > the kernel emitted DWARF5, but pahole was built with libraries that > > didn't support it yet? Not sure how that fits with the fact that > > To check that please tweak: > > ⬢[acme@toolbox perf-tools-next]$ grep DWARF ../build/v6.2-rc5+/.config > CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y > # CONFIG_DEBUG_INFO_DWARF4 is not set > # CONFIG_DEBUG_INFO_DWARF5 is not set > ⬢[acme@toolbox perf-tools-next]$ > > i.e. disable CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT and enable > CONFIG_DEBUG_INFO_DWARF4. Hm, with CONFIG_DEBUG_INFO_DWARF4, no warning were shown. LD .tmp_vmlinux.btf BTF .btf.vmlinux.bin.o LD .tmp_vmlinux.kallsyms1 And / # strings /sys/kernel/btf/vmlinux | wc -l 89921 / # strings /sys/kernel/btf/vmlinux | grep -w kfree kfree It seems the BTF is correctly generated. (with DWARF5, the number of symbols are about 30000.) Maybe we should check the pahole version and choose the DWARF4 if BTF is selected. Thank you! > > - Arnaldo > > > pahole v1.22 works though. If you have a chance, it might be worth > > experimenting with your kernel .config to specify DWARF4 to see if > > that makes a difference. > > > > You can check DWARF version associated with CUs with > > > > readelf --debug-dump=info vmlinux |grep -A 2 'Compilation Unit' -- Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>
