Re: [PATCH dwarves] pahole: Avoid generating artificial inlined functions for BTF

[Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>]

On October 21, 2025 11:32:08 AM GMT-03:00, Alan Maguire <alan.maguire@oracle.com> wrote:
>On 21/10/2025 13:32, Jakub Sitnicki wrote:
>> On Fri, Oct 03, 2025 at 10:36 AM -07, Yonghong Song wrote:
>>> But actually, one of function 'foo' is marked as DW_INL_inlined which means
>>> we should not treat it as an elf funciton. The patch fixed this issue
>>> by filtering subprograms if the corresponding function__inlined() is true.
>> 
>> I have a semi-related question: are there any plans for BTF to indicate
>> when a function has been inlined? Not necessarily where it has been
>> inlined, just that it has, somewhere, at least once.
>> 
>> When tracing with bpftrace or perf without a vmlinux available, it's
>> easy to assume you're tracing all calls to a function, when in fact some
>> calls may be inlined within the same compilation unit.
>> 
>> A good example is tracing the rtnl_lock - there are multiple inlined
>> copies, but neither bpftrace nor perf can warn you about it when debug
>> info is absent.
>> 
>
>hi Jakub, see the RFC series at [1]. The goal is to represent inline
>sites in BTF such that we can see when a function has been partially or
>fully inlined, or indeed when optimizations have been applied to its ,
>parameters which result in it being unsafe for fprobe()ing - in these
>cases we skip representing such functions in BTF today.

I wonder if at least telling the user that there are such optimized cases around line N on function F, etc it could help with workarounds while tracing.

I.e. represent it in BTF and let tools decide it's unsafe and use it just for these warnings.

>In the case of inlined/optimized functions the proposal is to represent
>them via BTF location data; not all of these locations will have all
>parameters available due to optimization etc. However even absent that
>it is still valuable to know such inlining has occurred as you say.

Oh well, that's what you propose 8-)

>
>[1]
>https://lore.kernel.org/bpf/20251008173512.731801-1-alan.maguire@oracle.com/
>
>> $ sudo perf probe -a rtnl_lock
>> Added new event:
>>   probe:rtnl_lock      (on rtnl_lock)
>>  
>> You can now use it in all perf tools, such as:
>>  
>>         perf record -e probe:rtnl_lock -aR sleep 1
>>  
>> $ sudo apt install linux-image-`uname -r`-dbg
>> Installing:
>>   linux-image-6.12.53-cloudflare-2025.10.4-dbg
>> […]
>> $ sudo perf probe -d rtnl_lock
>> Removed event: probe:rtnl_lock
>> $ sudo perf probe -a rtnl_lock
>> Added new events:
>>   probe:rtnl_lock      (on rtnl_lock)
>>   probe:rtnl_lock      (on rtnl_lock)
>>   probe:rtnl_lock      (on rtnl_lock)
>>   probe:rtnl_lock      (on rtnl_lock)
>>   probe:rtnl_lock      (on rtnl_lock)
>>   probe:rtnl_lock      (on rtnl_lock)
>>   probe:rtnl_lock      (on rtnl_lock)
>>   probe:rtnl_lock      (on rtnl_lock)
>>   probe:rtnl_lock      (on rtnl_lock)
>>   probe:rtnl_lock      (on rtnl_lock)
>>   probe:rtnl_lock      (on rtnl_lock)
>>  
>> You can now use it in all perf tools, such as:
>>  
>>         perf record -e probe:rtnl_lock -aR sleep 1
>>  
>> $
>> 
>> Thanks,
>> -jkbs
>

- Arnaldo