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

[Jiri Olsa <olsajiri@gmail.com>]

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,
jirka