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]> ... > 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__ */ ...
