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

On Mon, Sep 14, 2026 at 03:29:21PM +0100, Alan Maguire wrote:

On 11/09/2026 20:26, Jiri Olsa wrote:

quoted

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

quoted

+
+/*
+ * 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