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

[Alan Maguire <alan.maguire@oracle.com>]

On 09/09/2026 23:26, Eduard Zingerman wrote:
> 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>
>

Thanks for reviewing all of this, much appreciated! Replies below..
 
> ...
> 
>> 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?
> 

much clearer; will do.

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

thanks, will fix.

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

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.

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

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