Re: [PATCH v5 dwarves 05/10] pahole: Support inline BTF location encoding

[Jiri Olsa <olsajiri@gmail.com>]

On Fri, Oct 09, 2026 at 06:32:43PM +0100, Alan Maguire wrote:
> On 09/10/2026 14:12, Jiri Olsa wrote:
> > 
> > On Fri, Oct 02, 2026 at 06:40:33PM +0100, Alan Maguire wrote:
> > 
> > SNIP
> > 
> >> +static int btf_encoder__add_inline_expansion(struct btf_encoder *encoder,
> >> +					     struct inline_expansion *ie)
> >> +{
> >> +	struct ftype *ftype;
> >> +	struct loc *loc;
> >> +	struct parameter *param;
> >> +	uint32_t section_idx, section_offset;
> >> +	int err;
> >> +
> >> +	if (!ie->function || !ie->name ||
> >> +	    !btf_encoder__inline_addr_to_section(encoder, ie->ip.addr,
> >> +						 &section_idx, &section_offset))
> >> +		return 0;
> > 
> > hi,
> > we get inline locations also from .init.text, which then fail kprobe
> > address validation.. is there some usecase for keeping .init.text
> > locations?
> > 
> > I currently disable them in kprobe_multi change I have on top of this,
> > but I wonder we could just drop them completely in here with something
> > like:
> > 
> > 	if (strstarts(encoder->secinfo[section_idx].name, ".init"))
> > 		return 0;
> > 
> > thanks,
> > jirka
> >
> 
> hi Jiri,
> 
> Yeah, it's a great point, and certainly doable. I guess the question is 
> if they would ever be useful? Are there any cases like early boot-time
> tracing that might find them useful at some point say? Or even informationally -
> i.e. function foo() is inlined 700 times in the kernel, 20 in .init.text
> and 680 in .text. Not sure..

actualy looks like ftrace might be able to trwce early after boot, so it
might be handy if we manage to use this via ftrace

> 
> On my kernel the inline.init.text sites are ~2% of the overall number of 
> sites, so it's not nothing in terms of storage, but a lot less than the 
> .text section. So I'm happy to filter them out if we think it makes sense;
> maybe we should add a section option to the inline feature or something?

so it's like around 200kB? I this it's ok to keep it, nevermind ;-)

thanks,
jirka