On Mon, 2025-02-10 at 22:42 +0000, Ihor Solodrai wrote: > 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@xxxxx> > > > > > > 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? See tools/lib/bpf/libbpf.c:bpf_object__sanitize_btf(). A set of small in-place rewrites for compatibility with old kernels. > 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. Makes sense. [...]
