Re: [PATCH dwarves 0/3] pahole: Replace or add functions with true signatures in btf

[Alan Maguire <alan.maguire@oracle.com>]

On 11/11/2025 17:04, Yonghong Song wrote:
> Current vmlinux BTF encoding is based on the source level signatures.
> But the compiler may do some optimization and changed the signature.
> If the user tried with source level signature, their initial implementation
> may have wrong results and then the user need to check what is the
> problem and work around it, e.g. through kprobe since kprobe does not
> need vmlinux BTF. 
> 
> The following is a concrete example for [1].
> The original source signature:
>   typedef struct {
>         union {
>                 void            *kernel;
>                 void __user     *user;
>         };
>         bool            is_kernel : 1;
>   } sockptr_t;
>   typedef sockptr_t bpfptr_t;
>   static int map_create(union bpf_attr *attr, bpfptr_t uattr) { ... }
> After compiler optimization, the signature becomes:
>   static int map_create(union bpf_attr *attr, bool uattr__coerce1) { ... }
>   
> In the above, uattr__coerce1 corresponds to 'is_kernel' field in sockptr_t.
> Here, the suffix '__coerce1' refers to the second 64bit value in
> sockptr_t. The first 64bit value will be '__coerce0' if that value
> is used instead.
> 
> To do proper tracing, it would be good for the users to know the
> changed signature. With the actual signature, both kprobe and fentry
> should work as usual. This can avoid user surprise and improve
> developer productivity.
> 
> The llvm compiler patch [1] collects true signature and encoded those
> functions in dwarf. pahole will process these functions and
> replace old signtures with true signatures. Additionally,
> new functions (e.g., foo.llvm.<hash>) can be encoded in
> vmlinux BTF as well.
> 
> Patches 1/2 are refactor patches. Patch 3 has the detailed explanation
> in commit message and implements the logic to encode replaced or new
> signatures to vmlinux BTF. Please see Patch 3 for details.
>


Thanks for sending the series Yonghong! I think the thing we need to
discuss at a high level is this; what is the proposed relationship
between source code and BTF function encoding? The approach we have
taken thus far is to use source level as the basis for encoding, and as
part of that we attempt to identify cases where the source-level
expectations are violated by the compiled (optimized) code. We currently
do not encode those cases as in the case of optimized-out parameters,
source-level expectations of parameter position could lead to bad
behaviour. There are probably cases we miss in this, but that is the
intent at least.

There are however cases where .isra-suffixed functions retain the
expected parameter representations; in such cases we encode with the
prefix name ("foo" not "foo.isra.0") as DWARF does.

So in moving away from that, I think we need to make a clear decision
and have handling in place. My practical worry is that users trying to
write BPF progs cannot easily predict if a parameter is optimized out
and so on, so it's hard to write stable BPF programs for such
signatures. Less of a problem if using a high-level tracer I suppose.

The approach I had been thinking about was to utilize BTF location
information for such cases, but the RFC [1] didn't get around to
implementing the support. So the idea would be have location info with
parameter types and locations, but because we don't encode a function
fentry can't be used (but kprobes still could as for inline sites). So
under that scheme the foo.llvm.hash functions could still be called
"foo" since we have address information for the sites we can match foo
to foo.llvm.hash.

Anyway I'd appreciate other perspectives here. We have implicitly tied
BTF function encoding thus for to source-level representation for
reasons of fentry safety, but we could potentially move away from that.
Doing so though would I think at a minimum require machinery for fentry
safety to preserved, but we could find other ways to flag this in the
BTF function representation potentially. Thanks!

Alan


[1]
https://lore.kernel.org/bpf/20251024073328.370457-1-alan.maguire@oracle.com/

>   [1] https://github.com/llvm/llvm-project/pull/165310
> 
> Yonghong Song (3):
>   btf_encoder: Refactor elf_functions__new() with struct btf_encoder as
>     argument
>   bpf_encoder: Refactor a helper elf_function__check_and_push_sym()
>   pahole: Replace or add functions with true signatures in btf
> 
>  btf_encoder.c  | 79 +++++++++++++++++++++++++++++++++++---------
>  dwarf_loader.c | 89 ++++++++++++++++++++++++++++++++++++++++++++++++++
>  dwarves.h      |  4 +++
>  pahole.c       |  9 +++++
>  4 files changed, 165 insertions(+), 16 deletions(-)
>