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? > $ pahole --verbose -J $PAHOLE_FLAGS vmlinux > /tmp/pahole.out > die__process: DW_TAG_compile_unit, DW_TAG_type_unit, DW_TAG_partial_unit or DW_TAG_skeleton_unit expected got INVALID (0x0)! > > OK, so something failed. > > $ grep skipping /tmp/pahole.out | wc -l > 0 > > Nothing to be skipped. > > $ grep -w kfree /tmp/pahole.out | wc -l > 0 > $ grep -w vfs_read /tmp/pahole.out | wc -l > 0 > > But both kfree and vfs_read are not found. > > $ perf probe -k ./vmlinux -V kfree > Available variables at kfree > @<kfree+0> > (unknown_type) object > $ perf probe -k ./vmlinux -V vfs_read > Available variables at vfs_read > @<vfs_read+0> > char* buf > loff_t* pos > size_t count > struct file* file > > However, perf probe can find both in the DWARF info. > > Thank you, > Unfortunately (or fortunately?) I haven't been able to reproduce so far I'm afraid. I used your config and built gcc 13 from source; everything worked as expected, with no warnings or missing functions (aside from the ones skipped due to inconsistent prototypes etc). One other thing I can think of - is it possible libdw[arf]/libelf versions might be having an effect here? I'm using libdwarf.so.1.2, libdw-0.188, libelf-0.188. I can try and match yours. Thanks! Alan
