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 <[email protected]>
>> ---
>
> Acked-by: Eduard Zingerman <[email protected]>
>
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__ */
>
> ...
>
>
