From: Ihor Solodrai <ihor.solodrai@linux.dev>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Eduard Zingerman <eddyz87@gmail.com>,
Kumar Kartikeya Dwivedi <memxor@gmail.com>,
Alan Maguire <alan.maguire@oracle.com>,
Jiri Olsa <jolsa@kernel.org>,
bpf@vger.kernel.org, linux-kbuild@vger.kernel.org,
Emil Tsalapatis <emil@etsalapatis.com>
Subject: Re: [PATCH bpf-next v1 05/14] resolve_btfids: Index BTF ID symbols by address
Date: Tue, 16 Jun 2026 14:47:02 -0700 [thread overview]
Message-ID: <2d2329ac-5394-4eac-926a-990c83eabaa1@linux.dev> (raw)
In-Reply-To: <CAEf4BzYevwUOY34KOdjRd9cv5uXdxEwy13+6vHmNo_h4ryyT5g@mail.gmail.com>
On 6/3/26 4:45 PM, Andrii Nakryiko wrote:
> On Mon, Jun 1, 2026 at 3:19 PM Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
>>
>> Keep an address-sorted index of parsed .BTF_ids symbols so code that
>> the original BTF_ID symbol name can be recovered from an entry
>> address.
>>
>> Use the index in find_kfunc_flags() to scan BTF_SET8_KFUNCS entries
>> directly and match each entry back to the requested kfunc.
>>
>> Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev>
>> ---
>> tools/bpf/resolve_btfids/main.c | 103 +++++++++++++++++++++++++-------
>> 1 file changed, 80 insertions(+), 23 deletions(-)
>>
>> diff --git a/tools/bpf/resolve_btfids/main.c b/tools/bpf/resolve_btfids/main.c
>> index f8a91fa7584f..43512af13148 100644
>> --- a/tools/bpf/resolve_btfids/main.c
>> +++ b/tools/bpf/resolve_btfids/main.c
>> @@ -119,6 +119,11 @@ struct btf_id {
>> Elf64_Addr addr[ADDR_CNT];
>> };
>>
>> +struct addr_sym {
>> + Elf64_Addr addr;
>> + const char *name;
>> +};
>> +
>> struct object {
>> const char *path;
>> const char *btf_path;
>> @@ -150,6 +155,10 @@ struct object {
>> int nr_structs;
>> int nr_unions;
>> int nr_typedefs;
>> +
>> + struct addr_sym *addr_syms;
>> + int nr_addr_syms;
>> + int max_addr_syms;
>
> nit: max seems misnamed, it's "capacity", so I'd choose
> "addr_syms_cnt" and "addr_syms_cap" naming (I believe libbpf does that
> relatively consistently)
>
>> };
>>
>> #define KF_IMPLICIT_ARGS (1 << 16)
>
> [...]
>
>> for (next = rb_first(&obj->sets); next; next = rb_next(next)) {
>> set_id = rb_entry(next, struct btf_id, rb_node);
>> if (set_id->kind != BTF_ID_KIND_SET8 || set_id->addr_cnt != 1)
>> continue;
>>
>> - set_lower_addr = set_id->addr[0];
>> - set_upper_addr = set_lower_addr + set_id->cnt * sizeof(u64);
>> + set_addr = set_id->addr[0];
>> + idx = (set_addr - obj->efile.idlist_addr) / sizeof(u32) + 1;
>
> where is this +1 coming from? we have some reserved zero entry in
> .BTF_ids section? I'd understand if this was symbols table, where we
> do have zero entry, but I'm not quite following here...
We do a +1 in find_kfunc_flags() three times for slightly different reasons:
// Here we extract the *set* flags from the header
idx = (set_addr - obj->efile.idlist_addr) / sizeof(u32) + 1;
set_flags = elf_data_ptr[idx];
[...]
// here we skip the btf_id_set header
Elf64_Addr addr = set_addr + sizeof(u64) * (i + 1);
[...]
// and here we extract the flags from a pair
idx = (addr - obj->efile.idlist_addr) / sizeof(u32) + 1;
return elf_data_ptr[idx];
I think the way to make it less confusing is to cast the data pointer
to struct btf_id_set8 before inspecting it, and read the fields.
I'll do that in v2.
>
>
>
>> + set_flags = elf_data_ptr[idx];
>> + if (!(set_flags & BTF_SET8_KFUNCS))
>> + continue;
>>
>> - for (u32 i = 0; i < kfunc_id->addr_cnt; i++) {
>> - addr = kfunc_id->addr[i];
>> - /*
>> - * Lower bound is exclusive to skip the 8-byte header of the set.
>> - * Upper bound is inclusive to capture the last entry at offset 8*cnt.
>> - */
>> - if (set_lower_addr < addr && addr <= set_upper_addr) {
>> - pr_debug("found kfunc %s in BTF_ID_FLAGS %s\n",
>> - kfunc_id->name, set_id->name);
>> - idx = addr - obj->efile.idlist_addr;
>> - idx = idx / sizeof(u32) + 1;
>> - flags = elf_data_ptr[idx];
>> -
>> - return flags;
>> - }
>> + for (u32 i = 0; i < set_id->cnt; i++) {
>> + Elf64_Addr addr = set_addr + sizeof(u64) * (i + 1);
>> + const char *name = find_name_by_addr(obj, addr);
>> +
>> + if (!name || strcmp(name, kfunc_id->name) != 0)
>> + continue;
>> +
>> + pr_debug("found kfunc %s in BTF_ID_FLAGS %s\n",
>> + kfunc_id->name, set_id->name);
>> +
>> + idx = (addr - obj->efile.idlist_addr) / sizeof(u32) + 1;
>> + return elf_data_ptr[idx];
>> }
>> }
>>
>> @@ -1575,6 +1631,7 @@ int main(int argc, const char **argv)
>> btf_id__free_all(&obj.typedefs);
>> btf_id__free_all(&obj.funcs);
>> btf_id__free_all(&obj.sets);
>> + free(obj.addr_syms);
>> if (obj.efile.elf) {
>> elf_end(obj.efile.elf);
>> close(obj.efile.fd);
>> --
>> 2.54.0
>>
next prev parent reply other threads:[~2026-06-16 21:47 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-01 22:17 [PATCH bpf-next v1 00/14] resolve_btfids: Implement BTF tags emission for kfuncs Ihor Solodrai
2026-06-01 22:17 ` [PATCH bpf-next v1 01/14] tools/bpf: Sync btf_ids.h to tools Ihor Solodrai
2026-06-16 6:28 ` Emil Tsalapatis
2026-06-01 22:17 ` [PATCH bpf-next v1 02/14] selftests/bpf: Modernize resolve_btfids test scaffolding Ihor Solodrai
2026-06-02 13:02 ` Jiri Olsa
2026-06-02 18:30 ` Ihor Solodrai
2026-06-16 6:33 ` Emil Tsalapatis
2026-06-01 22:17 ` [PATCH bpf-next v1 03/14] selftests/bpf: Fix resolve_btfids test reads of BTF ID sets in PIE builds Ihor Solodrai
2026-06-03 23:45 ` Andrii Nakryiko
2026-06-16 20:15 ` Ihor Solodrai
2026-06-16 6:53 ` Emil Tsalapatis
2026-06-01 22:17 ` [PATCH bpf-next v1 04/14] selftests/bpf: Add kfunc set test to resolve_btfids Ihor Solodrai
2026-06-02 13:02 ` Jiri Olsa
2026-06-03 23:45 ` Andrii Nakryiko
2026-06-16 7:07 ` Emil Tsalapatis
2026-06-16 18:33 ` Alexei Starovoitov
2026-06-16 21:52 ` Ihor Solodrai
2026-06-01 22:17 ` [PATCH bpf-next v1 05/14] resolve_btfids: Index BTF ID symbols by address Ihor Solodrai
2026-06-01 22:28 ` sashiko-bot
2026-06-01 23:03 ` bot+bpf-ci
2026-06-02 13:01 ` Jiri Olsa
2026-06-02 18:28 ` Ihor Solodrai
2026-06-03 23:45 ` Andrii Nakryiko
2026-06-16 21:47 ` Ihor Solodrai [this message]
2026-06-16 18:45 ` Emil Tsalapatis
2026-06-16 21:53 ` Ihor Solodrai
2026-06-01 22:17 ` [PATCH bpf-next v1 06/14] resolve_btfids: Discover kfuncs from BTF ID sets Ihor Solodrai
2026-06-01 22:33 ` sashiko-bot
2026-06-02 18:36 ` Ihor Solodrai
2026-06-02 20:36 ` Jiri Olsa
2026-06-02 21:08 ` Ihor Solodrai
2026-06-03 23:45 ` Andrii Nakryiko
2026-06-03 23:45 ` Andrii Nakryiko
2026-06-16 21:49 ` Ihor Solodrai
2026-06-01 22:17 ` [PATCH bpf-next v1 07/14] resolve_btfids: Emit bpf_kfunc BTF decl tag for discovered kfuncs Ihor Solodrai
2026-06-03 23:45 ` Andrii Nakryiko
2026-06-01 22:17 ` [PATCH bpf-next v1 08/14] selftests/bpf: Verify bpf_kfunc decl tag emission in resolve_btfids Ihor Solodrai
2026-06-01 22:18 ` [PATCH bpf-next v1 09/14] resolve_btfids: Emit a decl tag for kfuncs with KF_FASTCALL Ihor Solodrai
2026-06-01 22:18 ` [PATCH bpf-next v1 10/14] selftests/bpf: Verify bpf_fastcall decl tags in resolve_btfids test Ihor Solodrai
2026-06-03 23:47 ` Andrii Nakryiko
2026-06-01 22:18 ` [PATCH bpf-next v1 11/14] resolve_btfids: Process KF_ARENA_* flags in resolve_btfids Ihor Solodrai
2026-06-03 23:47 ` Andrii Nakryiko
2026-06-16 19:51 ` Emil Tsalapatis
2026-06-16 20:36 ` Emil Tsalapatis
2026-06-16 21:58 ` Ihor Solodrai
2026-06-01 22:18 ` [PATCH bpf-next v1 12/14] selftests/bpf: Verify arena type tags in resolve_btfids test Ihor Solodrai
2026-06-01 22:29 ` sashiko-bot
2026-06-03 23:46 ` Andrii Nakryiko
2026-06-01 22:18 ` [PATCH bpf-next v1 13/14] kbuild: Drop decl_tag_kfuncs and attributes from pahole flags Ihor Solodrai
2026-06-03 23:48 ` Andrii Nakryiko
2026-06-01 22:18 ` [PATCH bpf-next v1 14/14] docs, resolve_btfids: Document kfunc BTF annotation emission Ihor Solodrai
2026-06-16 19:54 ` Emil Tsalapatis
2026-06-03 23:45 ` [PATCH bpf-next v1 00/14] resolve_btfids: Implement BTF tags emission for kfuncs Andrii Nakryiko
2026-06-16 20:10 ` Ihor Solodrai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2d2329ac-5394-4eac-926a-990c83eabaa1@linux.dev \
--to=ihor.solodrai@linux.dev \
--cc=alan.maguire@oracle.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=jolsa@kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=memxor@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox