Re: [PATCH dwarves v7 0/5] pahole: Encode true signatures in kernel BTF

Alan Maguire <[email protected]> Tue, 23 Jun 2026 14:11:29 +0100
Newsgroups org.kernel.vger.dwarves,org.kernel.vger.bpf
Message-ID <[email protected]>
--------------OVh3Ckh0a5sG60cdyJgLcZDu
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 23/06/2026 13:28, Jiri Olsa wrote:
> On Mon, Jun 22, 2026 at 09:07:04PM -0700, 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.
>>
>> Majority of changed signatures are due to dead argument elimination.
>> The following is a more complex one. 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__is_kernel) { ... }
>> In the above, uattr__is_kernel corresponds to 'is_kernel' field in sockptr_t.
>> This makes it easier for developers to understand what changed.
>>
>> The new signature needs to properly follow ABI specification based on
>> locations. Otherwise, that signature should be discarded. For example,
>>
>>     0x0242f1f7:   DW_TAG_subprogram
>>                     DW_AT_name      ("memblock_find_in_range")
>>                     DW_AT_calling_convention        (DW_CC_nocall)
>>                     DW_AT_type      (0x0242decc "phys_addr_t")
>>                     ...
>>     0x0242f22e:     DW_TAG_formal_parameter
>>                       DW_AT_location        (indexed (0x14a) loclist = 0x005595bc:
>>                          [0xffffffff87a000f9, 0xffffffff87a00178): DW_OP_reg5 RDI
>>                          [0xffffffff87a00178, 0xffffffff87a001be): DW_OP_reg14 R14
>>                          [0xffffffff87a001be, 0xffffffff87a001c7): DW_OP_entry_value(DW_OP_reg5 RDI), DW_OP_stack_value
>>                          [0xffffffff87a001c7, 0xffffffff87a00214): DW_OP_reg14 R14)
>>                       DW_AT_name    ("start")
>>                       DW_AT_type    (0x0242decc "phys_addr_t")
>>                       ...
>>     0x0242f239:     DW_TAG_formal_parameter
>>                       DW_AT_location        (indexed (0x14b) loclist = 0x005595e6:
>>                          [0xffffffff87a000f9, 0xffffffff87a00175): DW_OP_reg4 RSI
>>                          [0xffffffff87a00175, 0xffffffff87a001b8): DW_OP_reg3 RBX
>>                          [0xffffffff87a001b8, 0xffffffff87a001c7): DW_OP_entry_value(DW_OP_reg4 RSI), DW_OP_stack_value
>>                          [0xffffffff87a001c7, 0xffffffff87a00214): DW_OP_reg3 RBX)
>>                       DW_AT_name    ("end")
>>                       DW_AT_type    (0x0242decc "phys_addr_t")
>>                       ...
>>     0x0242f245:     DW_TAG_formal_parameter
>>                       DW_AT_location        (indexed (0x14c) loclist = 0x00559610:
>>                          [0xffffffff87a001e3, 0xffffffff87a001ef): DW_OP_breg4 RSI+0)
>>                       DW_AT_name    ("size")
>>                       DW_AT_type    (0x0242decc "phys_addr_t")
>>                       ...
>>     0x0242f250:     DW_TAG_formal_parameter
>>                       DW_AT_const_value     (4096)
>>                       DW_AT_name    ("align")
>>                       DW_AT_type    (0x0242decc "phys_addr_t")
>>                       ...
>>
>> The third argument should correspond to RDX for x86_64. But the location suggests that
>> the parameter value is stored in the address with 'RSI + 0'. It is not clear whether
>> the parameter value is stored in RDX or not. So we have to discard this funciton in
>> vmlinux BTF to avoid incorrect true signatures.
>>
>> For llvm, any function having
>>   DW_AT_calling_convention        (DW_CC_nocall)
>> in dwarf DW_TAG_subprogram will indicate that this function has signature changed.
>> I did experiment with latest bpf-next. For x86_64, there are 69103 kernel functions
>> and 875 kernel functions having signature changed. A series of patches are intended
>> to ensure true signatures are properly represented. Eventually, only 20 functions
>> cannot have true signatures due to locations.
> 
> hi,
> I tried to get the numbers from my setup and noticed that some new
> functions were included in BTF compared to the current version
> (functions diff attached below)
> 
> like for "arp_process" function the current pahole gives me:
> 
>   arp_process : skipping BTF encoding of function due to unexpected register usage for parameter
> 
> but it's included in BTF generated with the new pahole.
> 
> in addition to your explanation above also one of the commit says:
> 
>      - a parameter with no location, a constant value, or (for non-clang) no
>        register found is marked optimized out
> 
> please check below, it seems like 2nd argument of arp_process has no location,
> so iiuc it should not be included in BTF, right?
> 
> thanks,
> jirka
> 
>

thanks for catching this; it looks like we return a bit early before detecting
missing locations in the non-true-signature code. If you get a chance, would you 
mind trying the attached patch to see if it fixes the problem?

If the fix works and Yonghong is happy with it we can add it as a followup
and land the true signature series to save another round.
--------------OVh3Ckh0a5sG60cdyJgLcZDu
Content-Type: text/x-patch; charset=UTF-8;
 name="0001-dwarf_loader-Keep-clang-parameter-location-checks-wi.patch"
Content-Disposition: attachment;
 filename*0="0001-dwarf_loader-Keep-clang-parameter-location-checks-wi.pa";
 filename*1="tch"
Content-Transfer-Encoding: base64

RnJvbSA4M2Q0ZGJmZjJmODNkMzIyYzU1ZGVlZTBhNzFmMTU3ZTY4M2M5ZjE3IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBBbGFuIE1hZ3VpcmUgPGFsYW4ubWFndWlyZUBvcmFjbGUuY29t
PgpEYXRlOiBUdWUsIDIzIEp1biAyMDI2IDE0OjA4OjIxICswMTAwClN1YmplY3Q6IFtQQVRDSCBk
d2FydmVzXSBkd2FyZl9sb2FkZXI6IEtlZXAgY2xhbmcgcGFyYW1ldGVyIGxvY2F0aW9uIGNoZWNr
cwogd2l0aG91dCB0cnVlX3NpZ25hdHVyZQoKVGhlIHRydWVfc2lnbmF0dXJlIHNlcmllcyBnYXRl
ZCBjbGFuZyBwYXJhbWV0ZXIgbG9jYXRpb24gYW5hbHlzaXMgb24KdHJ1ZV9zaWduYXR1cmUgYmVp
bmcgZW5hYmxlZCBmb3IgZnVuY3Rpb25zIHdob3NlIHNpZ25hdHVyZSBjaGFuZ2VkLiAgVGhhdAph
bHNvIGRpc2FibGVkIHRoZSBleGlzdGluZyBzYWZldHkgY2hlY2sgdGhhdCByZWplY3RzIGZ1bmN0
aW9ucyB3aG9zZSBEV0FSRgpzb3VyY2UgcHJvdG90eXBlIG5vIGxvbmdlciBtYXRjaGVzIHRoZSBB
QkkgcmVnaXN0ZXIgbGF5b3V0LgoKRm9yIGV4YW1wbGUsIGNsYW5nIGNhbiBlbWl0IGEgRFdfQ0Nf
bm9jYWxsIGZ1bmN0aW9uIGxpa2U6CgogICAgYXJwX3Byb2Nlc3MobmV0LCBzaywgc2tiKQoKd2hl
cmUgc2sgaGFzIG5vIGxvY2F0aW9uIGFuZCBza2IgaXMgYWN0dWFsbHkgcGFzc2VkIGluIFJTSSwg
dGhlIHNsb3QKdGhhdCB0aGUgc291cmNlIHByb3RvdHlwZSB3b3VsZCBhc3NpZ24gdG8gc2suICBX
aXRoIGxvY2F0aW9uIGFuYWx5c2lzCmRpc2FibGVkLCBub3JtYWwgQlRGIGVuY29kaW5nIGNvdWxk
IGVtaXQgdGhlIG1pc2xlYWRpbmcgc291cmNlIHNpZ25hdHVyZQp3aGVuIHRydWVfc2lnbmF0dXJl
IHdhcyBvZmYuCgpBbHdheXMgZGVjb2RlIGFuZCBhbmFseXplIHBhcmFtZXRlciBsb2NhdGlvbnMu
ICBLZWVwIHRoZSB0cnVlLXNpZ25hdHVyZQpyZXdyaXRlcyBnYXRlZCBvbiB0cnVlX3NpZ25hdHVy
ZSwgYnV0IHByZXNlcnZlIHRoZSBsZWdhY3kgdW5leHBlY3RlZC1yZWdpc3RlcgpkZXRlY3Rpb24g
aW4gdGhlIGRpc2FibGVkIHBhdGguICBBbHNvIGluaXRpYWxpemUgbG9jX3JlZyBiZWZvcmUgZWFy
bHkgcmV0dXJucwpzbyBtaXNzaW5nIGFuYWx5c2lzIGNhbm5vdCBiZSBjb25mdXNlZCB3aXRoIERX
X09QX3JlZzAvUkFYLgoKU2lnbmVkLW9mZi1ieTogQWxhbiBNYWd1aXJlIDxhbGFuLm1hZ3VpcmVA
b3JhY2xlLmNvbT4KLS0tCiBkd2FyZl9sb2FkZXIuYyB8IDE2ICstLS0tLS0tLS0tLS0tLS0KIDEg
ZmlsZSBjaGFuZ2VkLCAxIGluc2VydGlvbigrKSwgMTUgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0
IGEvZHdhcmZfbG9hZGVyLmMgYi9kd2FyZl9sb2FkZXIuYwppbmRleCA5ZDUxZmY3Li41NTg4ZWQ5
IDEwMDY0NAotLS0gYS9kd2FyZl9sb2FkZXIuYworKysgYi9kd2FyZl9sb2FkZXIuYwpAQCAtMTUy
MCwxNCArMTUyMCw2IEBAIHN0YXRpYyB2b2lkIHBhcmFtZXRlcl9fZGVjb2RlX2xvY2F0aW9uKER3
YXJmX0F0dHJpYnV0ZSAqYXR0ciwgc3RydWN0IGNvbmZfbG9hZCAqCiAJcGFyYW1ldGVyX19maW5p
c2hfcGllY2VfZGVjb2RlKHBhcm0sIGRpZSwgY29uZiwgY3UpOwogfQogCi1zdGF0aWMgYm9vbCBm
dHlwZV9fYW5hbHl6ZV9sb2NhdGlvbnMoY29uc3Qgc3RydWN0IGZ0eXBlICpmdHlwZSwgY29uc3Qg
c3RydWN0IGN1ICpjdSwKLQkJCQkgICAgIGNvbnN0IHN0cnVjdCBjb25mX2xvYWQgKmNvbmYpCi17
Ci0JYm9vbCB0cnVlX3NpZ19lbmFibGVkID0gY29uZi0+dHJ1ZV9zaWduYXR1cmUgJiYgZnR5cGUt
PnNpZ25hdHVyZV9jaGFuZ2VkOwotCi0JcmV0dXJuICFjdS0+cHJvZHVjZXJfY2xhbmcgfHwgdHJ1
ZV9zaWdfZW5hYmxlZDsKLX0KLQogc3RhdGljIHN0cnVjdCBwYXJhbWV0ZXIgKnBhcmFtZXRlcl9f
bmV3KER3YXJmX0RpZSAqZGllLCBzdHJ1Y3QgY3UgKmN1LCBzdHJ1Y3QgY29uZl9sb2FkICpjb25m
LAogCQkJCQlzdHJ1Y3QgZnR5cGUgKmZ0eXBlLCBpbnQgcGFyYW1faWR4KQogewpAQCAtMTUzOSwx
MyArMTUzMSwxMCBAQCBzdGF0aWMgc3RydWN0IHBhcmFtZXRlciAqcGFyYW1ldGVyX19uZXcoRHdh
cmZfRGllICpkaWUsIHN0cnVjdCBjdSAqY3UsIHN0cnVjdCBjbwogCQl0YWdfX2luaXQoJnBhcm0t
PnRhZywgY3UsIGRpZSk7CiAJCXBhcm0tPm5hbWUgPSBhdHRyX3N0cmluZyhkaWUsIERXX0FUX25h
bWUsIGNvbmYpOwogCQlwYXJtLT5pZHggPSBwYXJhbV9pZHg7CisJCXBhcm0tPmxvY19yZWcgPSBQ
QVJBTUVURVJfVU5LTk9XTl9SRUc7CiAJCWlmICghZnR5cGUpCiAJCQlyZXR1cm4gcGFybTsKIAot
CQlpZiAoIWZ0eXBlX19hbmFseXplX2xvY2F0aW9ucyhmdHlwZSwgY3UsIGNvbmYpKQotCQkJcmV0
dXJuIHBhcm07Ci0KLQkJcGFybS0+bG9jX3JlZyA9IFBBUkFNRVRFUl9VTktOT1dOX1JFRzsKIAkJ
cGFybS0+dHlwZV9ieXRlX3NpemUgPSBnZXRfdHlwZV9ieXRlX3NpemUoZGllLCBjdSk7CiAJCXBh
cm0tPnBhc3NlZF9pbl9tZW1vcnkgPSBwYXJtLT50eXBlX2J5dGVfc2l6ZSA+CiAJCQkoY3UtPmFn
Z191c2VfdHdvX3JlZ3MgPyAyICogY3UtPmFkZHJfc2l6ZSA6IGN1LT5hZGRyX3NpemUpOwpAQCAt
MzEyMiw5ICszMTExLDYgQEAgc3RhdGljIHZvaWQgZnVuY3Rpb25fX2FuYWx5emVfcGFyYW1ldGVy
X2xvY2F0aW9ucyhzdHJ1Y3QgZnVuY3Rpb24gKmZuLCBzdHJ1Y3QgY3UKIAlib29sIHRydWVfc2ln
X2VuYWJsZWQgPSBjb25mLT50cnVlX3NpZ25hdHVyZSAmJiBmdHlwZS0+c2lnbmF0dXJlX2NoYW5n
ZWQ7CiAJaW50IHJlZ19pZHggPSAwOwogCi0JaWYgKCFmdHlwZV9fYW5hbHl6ZV9sb2NhdGlvbnMo
ZnR5cGUsIGN1LCBjb25mKSkKLQkJcmV0dXJuOwotCiAJZnR5cGVfX2Zvcl9lYWNoX3BhcmFtZXRl
cihmdHlwZSwgcG9zKSB7CiAJCWJvb2wgY29uc3VtZXNfcmVnaXN0ZXIgPSB0cnVlOwogCQlib29s
IHJlZ3NfYXZhaWxhYmxlID0gcmVnX2lkeCA8IGN1LT5ucl9yZWdpc3Rlcl9wYXJhbXM7Ci0tIAoy
LjQzLjUKCg==

--------------OVh3Ckh0a5sG60cdyJgLcZDu--