Re: [RESEND] BTF is not generated for gcc-built kernel with the latest pahole

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux