Re: [PATCH v2 bpf-next 01/18] btf: Extend UAPI to support BTF location (inline site) info

[Jiri Olsa <olsajiri@gmail.com>]

On Mon, Sep 14, 2026 at 03:29:21PM +0100, Alan Maguire wrote:
> On 11/09/2026 20:26, Jiri Olsa wrote:
> > On Tue, Sep 01, 2026 at 05: 57: 40PM +0100, Alan Maguire wrote: SNIP > + > +/* > + * BTF_KIND_LOC_PROTO specifies location prototypes; i. e. how locations relate > + * to parameters; a struct btf_type of BTF_KIND_LOC_PROTO is followed
> > 
> > 
> > On Tue, Sep 01, 2026 at 05:57:40PM +0100, Alan Maguire wrote:
> > 
> > SNIP
> > 
> >> +
> >> +/*
> >> + * BTF_KIND_LOC_PROTO specifies location prototypes; i.e. how locations relate
> >> + * to parameters; a struct btf_type of BTF_KIND_LOC_PROTO is followed by a
> >> + * a vlen-specified number of __u32 BTF type ids which specify the associated
> >> + * BTF_KIND_LOC_PARAM for each function parameter associated with the
> >> + * location.  The type should either be 0 (no location info) or point at
> >> + * a BTF_KIND_LOC_PARAM.
> >> + */
> >> +
> >> +/*
> >> + * BTF_KIND_LOCSEC consists of vlen-specified number of "struct btf_loc"
> >> + * containing location site-specific information;
> >> + *
> >> + * - function (func)
> >> + * - location prototype type id (loc_proto)
> >> + * - address offset (offset) relative to kernel base address
> >> + */
> >> +
> >> +struct btf_loc {
> >> +	__u32 func;
> >> +	__u32 loc_proto;
> >> +	__u32 offset;
> >> +};
> > 
> > would it be possible to include btf id of the immediate parent function?
> > we have use cases for tracing just inlined function called from particular
> > parent
> > 
> > I thought we could use the location offset for that, but because inline
> > functions could be nested, this seems like hard search.. also we do not
> > know the size of the inlined code, so not sure how reliable it'd be
> > 
> > I checked the dwarves code and I wonder we could instead store parent
> > function (struct inline_expansion) during dwarf decoding and use that
> > later to get parent function FUNC_ID and have:
> > 
> > 	struct btf_loc {
> > 	     __u32 func;
> > 	     __u32 parent;
> > 	     __u32 loc_proto;
> > 	     __u32 offset;
> > 	};
> > 
> > wdyt? thanks,
> 
> hi Jiri,
> 
> So in the case of encoding the immediate parent it is quite expensive -
> my concern is that adding it as an extra field is another 4 bytes per BTF
> location, and because there are a lot of inline sites that would mean
> somewhere in the region of 4 * 500000 = 2Mb extra. This is the tricky part
> with this stuff; even small per-site tweaks really add up.

ugh right..

> 
> Is the immediacy of the parent-child relationship a dealbreaker for your
> use-case? As you say the offset can tell us the function B was inlined

it's one of the use cases, but it's still useful without this

> within the bounds of uninlined function A, but it won't tell us if it was
> via function C. The other thing that complicates this is that an inlining
> doesn't always have a size; it can be inlined in a non-contiguous manner.
> So in some ways maybe the best we can do anyway is to be able to say a
> function was inlined in a particular uninlined function?

I guess we could get that info from dwarf, it'd just be simpler 
having that in BTF

thanks,
jirka