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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.