On Mon, 2024-05-13 at 17:25 +0100, Alan Maguire wrote: > On 11/05/2024 10:40, Eduard Zingerman wrote: > > On Fri, 2024-05-10 at 11:30 +0100, Alan Maguire wrote: > > > Options cover existing parsing scenarios (ELF, raw, retrieving > > > .BTF.ext) and also allow specification of the ELF section name > > > containing BTF. This will allow consumers to retrieve BTF from > > > .BTF.base sections (BTF_BASE_ELF_SEC) also. > > > > > > Signed-off-by: Alan Maguire <alan.maguire@xxxxxxxxxx> > > > --- > > > > For the sake of discussion, what are the benefits of adding > > btf__parse_opts(), compared to modifying btf__parse() to check if > > .BTF.base is present and acting accordingly? > > btf__parse() already does a guess if passed argument is an ELF or a > > RAW file, so such guessing semantics seems to be a natural extension. > > It's a good idea. The only thing I'd say against it is that we already > have existing semantics there that are well-established, and the > .BTF.base scenario will be relatively rare, yet the check would I think > be a tax all .BTF-only cases will have to pay. We'd presumably check > .BTF.base, and if not present check for .BTF. So all callers of > btf__parse() when accessing .BTF sections would be checking for > .BTF.base first. You are talking about the cost of scanning all sections in the ELF file, right? It looks like btf.c:btf_parse_elf() already scans all sections once, maybe this code could be re-organized slightly to parse the base if .BTF.base section is present? Does not seem that this would incur a measurable runtime cost. Or do you have something else in mind? > In that context, it seemed to make sense to support an explicit request > for a specific section (via btf__parse_opts()) rather than inducing > overhead in existing checks. But again, if the overhead isn't seen as an > issue, we could absolutely do it.
