public inbox for bpf@vger.kernel.org
 help / color / mirror / Atom feed
From: "Ihor Solodrai" <ihor.solodrai@linux.dev>
To: "Eduard Zingerman" <eddyz87@gmail.com>,
	dwarves@vger.kernel.org, bpf@vger.kernel.org
Cc: acme@kernel.org, alan.maguire@oracle.com, ast@kernel.org,
	andrii@kernel.org, mykolal@fb.com, kernel-team@meta.com
Subject: Re: [PATCH dwarves 1/3] btf_encoder: collect kfuncs info in btf_encoder__new
Date: Mon, 10 Feb 2025 22:42:37 +0000	[thread overview]
Message-ID: <20a49b2ada87ce106607e1ca8c98a76e826dccd1@linux.dev> (raw)
In-Reply-To: <3782640a577e6945c86d6330bc8a05018a1e5c52.camel@gmail.com>

On 2/10/25 12:57 PM, Eduard Zingerman wrote:
> On Thu, 2025-02-06 at 18:14 -0800, Ihor Solodrai wrote:
>> From: Ihor Solodrai <ihor.solodrai@pm.me>
>>
>> btf_encoder__tag_kfuncs() is a post-processing step of BTF encoding,
>> executed right before BTF is deduped and dumped to the output.
>>
>> Split btf_encoder__tag_kfuncs() routine in two parts:
>>   * btf_encoder__collect_kfuncs()
>>   * btf_encoder__tag_kfuncs()
>>
>> [...]
>
> Tbh, I don't think this split is necessary, modifying btf_type
> in-place should be fine (and libbpf does it at-least in one place).
> E.g. like here:
> https://github.com/acmel/dwarves/compare/master...eddyz87:dwarves:arena-attrs-no-split
> I like it because it keeps the change a bit more contained,
> but I do not insist.

There are a couple of reasons this split makes sense to me.

First, I wanted to avoid modifying BTF. Having btf_encoder only
appending things to BTF is easy to reason about. But you're saying
modification does happen somewhere already?

The second reason is that the input for kfunc tagging is ELF, and so
it can be read at around the same time other ELF data is read (such as
for fucntions table). This has an additional benefit of running in
parallel to dwarf encoders (because one of the dwarf workers is
creating btf_encoder struct), as opposed to a sequential
post-processing step.

Finally I think it is generally useful to have kfunc info available at
any point of btf encoding, which becomes possible if the BTF_ids
section is read at the beginning of the encoding process.

>
> [...]
>>  
>> -		err = btf_encoder__tag_kfunc(encoder, &btf_funcs, func, pair->flags);
>> -		if (err) {
>> -			fprintf(stderr, "%s: failed to tag kfunc '%s'\n", __func__, func);
>> -			free(func);
>> +		elf_fn = btf_encoder__find_function(encoder, func, 0);
>> +		free(func);
>> +		if (!elf_fn)
>> +			continue;
>> +		elf_fn->kfunc = true;
>> +
>> +		kfunc = calloc(1, sizeof(*kfunc));
>> +		if (!kfunc) {
>> +			fprintf(stderr, "%s: failed to allocate memory for kfunc info\n", __func__);
>> +			err = -ENOMEM;
>>  			goto out;
>>  		}
>> -		free(func);
>> +		kfunc->id = pair->id;
>> +		kfunc->flags = pair->flags;
>> +		kfunc->name = elf_fn->name;
>
> If we do go with split, maybe make refactoring a bit more drastic and
> merge kfunc_info with elf_function?
> This would make maintaining a separate encoder->kfuncs list unnecessary.
> Also, can get rid of separate 'struct gobuffer *funcs'.
> E.g. see my commit on top of yours:
> https://github.com/acmel/dwarves/compare/master...eddyz87:dwarves:arena-attrs-merge-kfunc-info

Yeah, I like it. I'll play with this for v2, thanks.

>
>> +		list_add(&kfunc->node, &encoder->kfuncs);
>>  	}
>>  
>>  	err = 0;
>>  out:
>> -	__gobuffer__delete(&btf_funcs);
>>  	__gobuffer__delete(&btf_kfunc_ranges);
>>  	if (elf)
>>  		elf_end(elf);
>> @@ -2081,6 +2095,34 @@ out:
>>  	return err;
>>  }
>>  
>
> [...]
>

  reply	other threads:[~2025-02-10 22:42 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-07  2:14 [PATCH dwarves 0/3] btf_encoder: emit type tags for bpf_arena pointers Ihor Solodrai
2025-02-07  2:14 ` [PATCH dwarves 1/3] btf_encoder: collect kfuncs info in btf_encoder__new Ihor Solodrai
2025-02-10 20:57   ` Eduard Zingerman
2025-02-10 22:42     ` Ihor Solodrai [this message]
2025-02-11  0:35       ` Eduard Zingerman
2025-02-07  2:14 ` [PATCH dwarves 2/3] btf_encoder: emit type tags for bpf_arena pointers Ihor Solodrai
2025-02-10 22:11   ` Alan Maguire
2025-02-11  0:11     ` Ihor Solodrai
2025-02-07  2:14 ` [PATCH dwarves 3/3] pahole: introduce --btf_feature=attributes Ihor Solodrai
2025-02-10 22:13   ` Alan Maguire
2025-02-11  0:16     ` 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=20a49b2ada87ce106607e1ca8c98a76e826dccd1@linux.dev \
    --to=ihor.solodrai@linux.dev \
    --cc=acme@kernel.org \
    --cc=alan.maguire@oracle.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=dwarves@vger.kernel.org \
    --cc=eddyz87@gmail.com \
    --cc=kernel-team@meta.com \
    --cc=mykolal@fb.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