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

On 09/09/2026 23:26, Eduard Zingerman wrote:

On Tue, 2026-09-01 at 17:57 +0100, Alan Maguire wrote:

quoted

Add BTF_KIND_LOC_PARAM, BTF_KIND_LOC_PROTO and BTF_KIND_LOCSEC
to help represent location information for functions.

BTF_KIND_LOC_PARAM is used to represent how we retrieve data at a
location; either via register(s), or register+offset, a dereference
of a register+offset or a constant value.

BTF_KIND_LOC_PROTO represents location information about a location
with multiple BTF_KIND_LOC_PARAMs.

And finally BTF_KIND_LOCSEC is a set of location sites, each
of which has

- a BTF_KIND_FUNC function associated with the inline site
- a location prototype specifying where to find the function
  parameters
- an address offset relative to the kernel base address

This can be used to support representing

- a fully-inlined function at potentially multiple inline sites
  with potentially different parameter availability
- a partially-inlined function where some _LOC_PROTOs represent
  inlined sites as above and others have normal _FUNC representations

Also BTF_KIND_LOCSEC struct btf_loc will have two type id
references; one for the associated func, the other for the loc_proto.
Accordingly increase the number of m_offs references in btf_field_desc
to 2.

Signed-off-by: Alan Maguire <redacted>
---

Acked-by: Eduard Zingerman <eddyz87@gmail.com>

Thanks for reviewing all of this, much appreciated! Replies below..
 

...

quoted

diff --git a/include/linux/btf.h b/include/linux/btf.h
index ddd0f4f32d24..a4412bc16688 100644
--- a/include/linux/btf.h
+++ b/include/linux/btf.h

...

quoted

+static inline struct btf_loc_param *btf_loc_param(const struct btf_type *t)
+static inline __u32 *btf_loc_params(const struct btf_type *t)

Maybe rename the latter to btf_loc_proto_params?

much clearer; will do.

...

quoted

diff --git a/include/uapi/linux/btf.h b/include/uapi/linux/btf.h
index 618167cab4e6..6062c9958034 100644
--- a/include/uapi/linux/btf.h
+++ b/include/uapi/linux/btf.h

...

quoted

@@ -212,4 +214,65 @@ struct btf_enum64 {

 	__u32	val_hi32;
 };
 
+/*
+ * BTF_KIND_LOC_PARAM is followed by a single "struct btf_loc_param"
+ * that contains flags specifying the contents of the vlen-specified
+ * number of 4-byte values that follow.
+ */
+struct btf_loc_param {
+	__u32 flags;

Wdyt about adding a flexible array member here?

	__u32 params[];

Would make btf_loc_param_log() a little bit easier to follow.

quoted

+};
+
+/*
+ * The combination of size, vlen and flags gives us the means to interpret
+ * the following vlen-specified set of 4-byte values:
+ *
+ * - a BTF_LOC_PARAM_CONST is a constant value; combination
+ *   of size, vlen and _SIGNED flag determines it. If the value requires
+ *   64 bits it is stored in {lo,hi} order.
+ * - a BTF_LOC_PARAM_ADDR is an address that will be normalized with
+ *   respect to kernel base address.

Nit: pahole generates ADDR | CONST.

thanks, will fix.

quoted

+ * - a BTF_LOC_PARAM_REG with vlen 1 is a simple register number;
+ *   with vlen 2 it is a multi-register parameter.

Nit: REG | OFFSET is not discussed.

good catch.
 

yep, thanks for catching; I was experimenting to see if adding logical operators
bought us anything in terms of being able to encode more locations. Didn't really 
help so I left it out.

quoted

+ */
+enum btf_loc_param_flags {
+	BTF_LOC_PARAM_SIGNED		=	0x1,
+	BTF_LOC_PARAM_CONST		=	0x2,
+	BTF_LOC_PARAM_ADDR		=	0x4,
+	BTF_LOC_PARAM_REG		=	0x8,
+	BTF_LOC_PARAM_DEREF		=	0x10,
+	BTF_LOC_PARAM_OFFSET		=	0x20,
+};
+
+/*
+ * 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

pahole uses loc->section_offset to create LOCSEC entries,
which corresponds to an offset within an ELF containing
the function section. Would it make sense to rephrase the
above comment a bit?

yeah, adding a note on location naming would be good. I think it'd also be good
to call them inline<section> e.g. inline.text since it's possible locations could
be used for other purposes in the future.

quoted

+ */
+
+struct btf_loc {
+	__u32 func;
+	__u32 loc_proto;
+	__u32 offset;
+};
+
 #endif /* _UAPI__LINUX_BTF_H__ */

...