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

[Eduard Zingerman <eddyz87@gmail.com>]

On Tue, 2026-09-01 at 17:57 +0100, Alan Maguire wrote:
> 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 <alan.maguire@oracle.com>
> ---

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

...

> 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

...

> +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?

...

> 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

...

> @@ -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.

> +};
> +
> +/*
> + * 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.

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

> + * - a _REG | DEREF with vlen 1 dereferences the value in the register
> + *   number specified.
> + * - a REG | DEREF | OFFSET with vlen specifies the register value in
> + *   the first 4-byte value and the offset in the remainder.

--- >8 ---

> + * - binary logical operators operate on a combination of register
> + *   number and constant value, aside from _NOT which operates on
> + *   a register

--- 8< ---

This is probably a leftover.

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

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

...