^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) =====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2) BPF Type Format (BTF)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) =====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) 1. Introduction
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6) ***************
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) BTF (BPF Type Format) is the metadata format which encodes the debug info
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) related to BPF program/map. The name BTF was used initially to describe data
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) types. The BTF was later extended to include function info for defined
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) subroutines, and line info for source/line information.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) The debug info is used for map pretty print, function signature, etc. The
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) function signature enables better bpf program/function kernel symbol. The line
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) info helps generate source annotated translated byte code, jited code and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) verifier log.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) The BTF specification contains two parts,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) * BTF kernel API
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) * BTF ELF file format
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) The kernel API is the contract between user space and kernel. The kernel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) verifies the BTF info before using it. The ELF file format is a user space
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) contract between ELF file and libbpf loader.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) The type and string sections are part of the BTF kernel API, describing the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) debug info (mostly types related) referenced by the bpf program. These two
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) sections are discussed in details in :ref:`BTF_Type_String`.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) .. _BTF_Type_String:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) 2. BTF Type and String Encoding
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) *******************************
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) The file ``include/uapi/linux/btf.h`` provides high-level definition of how
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) types/strings are encoded.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) The beginning of data blob must be::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) struct btf_header {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) __u16 magic;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) __u8 version;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) __u8 flags;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) __u32 hdr_len;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) /* All offsets are in bytes relative to the end of this header */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) __u32 type_off; /* offset of type section */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) __u32 type_len; /* length of type section */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) __u32 str_off; /* offset of string section */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) __u32 str_len; /* length of string section */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) The magic is ``0xeB9F``, which has different encoding for big and little
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) endian systems, and can be used to test whether BTF is generated for big- or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) little-endian target. The ``btf_header`` is designed to be extensible with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) ``hdr_len`` equal to ``sizeof(struct btf_header)`` when a data blob is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) generated.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) 2.1 String Encoding
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) ===================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) The first string in the string section must be a null string. The rest of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) string table is a concatenation of other null-terminated strings.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) 2.2 Type Encoding
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) =================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) The type id ``0`` is reserved for ``void`` type. The type section is parsed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) sequentially and type id is assigned to each recognized type starting from id
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) ``1``. Currently, the following types are supported::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) #define BTF_KIND_INT 1 /* Integer */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) #define BTF_KIND_PTR 2 /* Pointer */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) #define BTF_KIND_ARRAY 3 /* Array */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) #define BTF_KIND_STRUCT 4 /* Struct */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) #define BTF_KIND_UNION 5 /* Union */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) #define BTF_KIND_ENUM 6 /* Enumeration */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) #define BTF_KIND_FWD 7 /* Forward */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) #define BTF_KIND_TYPEDEF 8 /* Typedef */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) #define BTF_KIND_VOLATILE 9 /* Volatile */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) #define BTF_KIND_CONST 10 /* Const */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82) #define BTF_KIND_RESTRICT 11 /* Restrict */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) #define BTF_KIND_FUNC 12 /* Function */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) #define BTF_KIND_FUNC_PROTO 13 /* Function Proto */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) #define BTF_KIND_VAR 14 /* Variable */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) #define BTF_KIND_DATASEC 15 /* Section */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) Note that the type section encodes debug info, not just pure types.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) ``BTF_KIND_FUNC`` is not a type, and it represents a defined subprogram.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91) Each type contains the following common data::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) struct btf_type {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) __u32 name_off;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) /* "info" bits arrangement
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) * bits 0-15: vlen (e.g. # of struct's members)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) * bits 16-23: unused
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) * bits 24-27: kind (e.g. int, ptr, array...etc)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) * bits 28-30: unused
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) * bit 31: kind_flag, currently used by
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) * struct, union and fwd
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) __u32 info;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) /* "size" is used by INT, ENUM, STRUCT and UNION.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) * "size" tells the size of the type it is describing.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106) *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) * "type" is used by PTR, TYPEDEF, VOLATILE, CONST, RESTRICT,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) * FUNC and FUNC_PROTO.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) * "type" is a type_id referring to another type.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) union {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) __u32 size;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) __u32 type;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) For certain kinds, the common data are followed by kind-specific data. The
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) ``name_off`` in ``struct btf_type`` specifies the offset in the string table.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) The following sections detail encoding of each kind.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) 2.2.1 BTF_KIND_INT
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122) ~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) ``struct btf_type`` encoding requirement:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125) * ``name_off``: any valid offset
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) * ``info.kind_flag``: 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) * ``info.kind``: BTF_KIND_INT
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128) * ``info.vlen``: 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) * ``size``: the size of the int type in bytes.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) ``btf_type`` is followed by a ``u32`` with the following bits arrangement::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) #define BTF_INT_ENCODING(VAL) (((VAL) & 0x0f000000) >> 24)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) #define BTF_INT_OFFSET(VAL) (((VAL) & 0x00ff0000) >> 16)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135) #define BTF_INT_BITS(VAL) ((VAL) & 0x000000ff)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) The ``BTF_INT_ENCODING`` has the following attributes::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139) #define BTF_INT_SIGNED (1 << 0)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140) #define BTF_INT_CHAR (1 << 1)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) #define BTF_INT_BOOL (1 << 2)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) The ``BTF_INT_ENCODING()`` provides extra information: signedness, char, or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) bool, for the int type. The char and bool encoding are mostly useful for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) pretty print. At most one encoding can be specified for the int type.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) The ``BTF_INT_BITS()`` specifies the number of actual bits held by this int
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148) type. For example, a 4-bit bitfield encodes ``BTF_INT_BITS()`` equals to 4.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) The ``btf_type.size * 8`` must be equal to or greater than ``BTF_INT_BITS()``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) for the type. The maximum value of ``BTF_INT_BITS()`` is 128.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) The ``BTF_INT_OFFSET()`` specifies the starting bit offset to calculate values
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) for this int. For example, a bitfield struct member has:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) * btf member bit offset 100 from the start of the structure,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156) * btf member pointing to an int type,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) * the int type has ``BTF_INT_OFFSET() = 2`` and ``BTF_INT_BITS() = 4``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) Then in the struct memory layout, this member will occupy ``4`` bits starting
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) from bits ``100 + 2 = 102``.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) Alternatively, the bitfield struct member can be the following to access the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163) same bits as the above:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) * btf member bit offset 102,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166) * btf member pointing to an int type,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167) * the int type has ``BTF_INT_OFFSET() = 0`` and ``BTF_INT_BITS() = 4``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169) The original intention of ``BTF_INT_OFFSET()`` is to provide flexibility of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170) bitfield encoding. Currently, both llvm and pahole generate
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171) ``BTF_INT_OFFSET() = 0`` for all int types.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173) 2.2.2 BTF_KIND_PTR
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) ~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176) ``struct btf_type`` encoding requirement:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) * ``name_off``: 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178) * ``info.kind_flag``: 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179) * ``info.kind``: BTF_KIND_PTR
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) * ``info.vlen``: 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) * ``type``: the pointee type of the pointer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183) No additional type data follow ``btf_type``.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185) 2.2.3 BTF_KIND_ARRAY
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) ~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) ``struct btf_type`` encoding requirement:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189) * ``name_off``: 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190) * ``info.kind_flag``: 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) * ``info.kind``: BTF_KIND_ARRAY
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192) * ``info.vlen``: 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193) * ``size/type``: 0, not used
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195) ``btf_type`` is followed by one ``struct btf_array``::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197) struct btf_array {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198) __u32 type;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) __u32 index_type;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) __u32 nelems;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203) The ``struct btf_array`` encoding:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204) * ``type``: the element type
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205) * ``index_type``: the index type
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) * ``nelems``: the number of elements for this array (``0`` is also allowed).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208) The ``index_type`` can be any regular int type (``u8``, ``u16``, ``u32``,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209) ``u64``, ``unsigned __int128``). The original design of including
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210) ``index_type`` follows DWARF, which has an ``index_type`` for its array type.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211) Currently in BTF, beyond type verification, the ``index_type`` is not used.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) The ``struct btf_array`` allows chaining through element type to represent
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214) multidimensional arrays. For example, for ``int a[5][6]``, the following type
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215) information illustrates the chaining:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217) * [1]: int
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218) * [2]: array, ``btf_array.type = [1]``, ``btf_array.nelems = 6``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219) * [3]: array, ``btf_array.type = [2]``, ``btf_array.nelems = 5``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221) Currently, both pahole and llvm collapse multidimensional array into
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222) one-dimensional array, e.g., for ``a[5][6]``, the ``btf_array.nelems`` is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223) equal to ``30``. This is because the original use case is map pretty print
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224) where the whole array is dumped out so one-dimensional array is enough. As
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225) more BTF usage is explored, pahole and llvm can be changed to generate proper
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226) chained representation for multidimensional arrays.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228) 2.2.4 BTF_KIND_STRUCT
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229) ~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230) 2.2.5 BTF_KIND_UNION
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231) ~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233) ``struct btf_type`` encoding requirement:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234) * ``name_off``: 0 or offset to a valid C identifier
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235) * ``info.kind_flag``: 0 or 1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236) * ``info.kind``: BTF_KIND_STRUCT or BTF_KIND_UNION
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237) * ``info.vlen``: the number of struct/union members
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238) * ``info.size``: the size of the struct/union in bytes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240) ``btf_type`` is followed by ``info.vlen`` number of ``struct btf_member``.::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 241)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 242) struct btf_member {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 243) __u32 name_off;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 244) __u32 type;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 245) __u32 offset;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 246) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 247)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 248) ``struct btf_member`` encoding:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 249) * ``name_off``: offset to a valid C identifier
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 250) * ``type``: the member type
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 251) * ``offset``: <see below>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 252)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 253) If the type info ``kind_flag`` is not set, the offset contains only bit offset
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 254) of the member. Note that the base type of the bitfield can only be int or enum
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 255) type. If the bitfield size is 32, the base type can be either int or enum
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 256) type. If the bitfield size is not 32, the base type must be int, and int type
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 257) ``BTF_INT_BITS()`` encodes the bitfield size.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 258)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 259) If the ``kind_flag`` is set, the ``btf_member.offset`` contains both member
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 260) bitfield size and bit offset. The bitfield size and bit offset are calculated
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 261) as below.::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 262)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 263) #define BTF_MEMBER_BITFIELD_SIZE(val) ((val) >> 24)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 264) #define BTF_MEMBER_BIT_OFFSET(val) ((val) & 0xffffff)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 265)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 266) In this case, if the base type is an int type, it must be a regular int type:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 267)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 268) * ``BTF_INT_OFFSET()`` must be 0.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 269) * ``BTF_INT_BITS()`` must be equal to ``{1,2,4,8,16} * 8``.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 270)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 271) The following kernel patch introduced ``kind_flag`` and explained why both
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 272) modes exist:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 273)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 274) https://github.com/torvalds/linux/commit/9d5f9f701b1891466fb3dbb1806ad97716f95cc3#diff-fa650a64fdd3968396883d2fe8215ff3
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 275)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 276) 2.2.6 BTF_KIND_ENUM
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 277) ~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 278)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 279) ``struct btf_type`` encoding requirement:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 280) * ``name_off``: 0 or offset to a valid C identifier
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 281) * ``info.kind_flag``: 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 282) * ``info.kind``: BTF_KIND_ENUM
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 283) * ``info.vlen``: number of enum values
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 284) * ``size``: 4
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 285)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 286) ``btf_type`` is followed by ``info.vlen`` number of ``struct btf_enum``.::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 287)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 288) struct btf_enum {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 289) __u32 name_off;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 290) __s32 val;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 291) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 292)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 293) The ``btf_enum`` encoding:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 294) * ``name_off``: offset to a valid C identifier
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 295) * ``val``: any value
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 296)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 297) 2.2.7 BTF_KIND_FWD
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 298) ~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 299)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 300) ``struct btf_type`` encoding requirement:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 301) * ``name_off``: offset to a valid C identifier
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 302) * ``info.kind_flag``: 0 for struct, 1 for union
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 303) * ``info.kind``: BTF_KIND_FWD
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 304) * ``info.vlen``: 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 305) * ``type``: 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 306)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 307) No additional type data follow ``btf_type``.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 308)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 309) 2.2.8 BTF_KIND_TYPEDEF
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 310) ~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 311)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 312) ``struct btf_type`` encoding requirement:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 313) * ``name_off``: offset to a valid C identifier
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 314) * ``info.kind_flag``: 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 315) * ``info.kind``: BTF_KIND_TYPEDEF
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 316) * ``info.vlen``: 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 317) * ``type``: the type which can be referred by name at ``name_off``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 318)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 319) No additional type data follow ``btf_type``.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 320)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 321) 2.2.9 BTF_KIND_VOLATILE
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 322) ~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 323)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 324) ``struct btf_type`` encoding requirement:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 325) * ``name_off``: 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 326) * ``info.kind_flag``: 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 327) * ``info.kind``: BTF_KIND_VOLATILE
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 328) * ``info.vlen``: 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 329) * ``type``: the type with ``volatile`` qualifier
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 330)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 331) No additional type data follow ``btf_type``.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 332)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 333) 2.2.10 BTF_KIND_CONST
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 334) ~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 335)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 336) ``struct btf_type`` encoding requirement:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 337) * ``name_off``: 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 338) * ``info.kind_flag``: 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 339) * ``info.kind``: BTF_KIND_CONST
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 340) * ``info.vlen``: 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 341) * ``type``: the type with ``const`` qualifier
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 342)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 343) No additional type data follow ``btf_type``.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 344)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 345) 2.2.11 BTF_KIND_RESTRICT
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 346) ~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 347)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 348) ``struct btf_type`` encoding requirement:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 349) * ``name_off``: 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 350) * ``info.kind_flag``: 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 351) * ``info.kind``: BTF_KIND_RESTRICT
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 352) * ``info.vlen``: 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 353) * ``type``: the type with ``restrict`` qualifier
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 354)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 355) No additional type data follow ``btf_type``.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 356)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 357) 2.2.12 BTF_KIND_FUNC
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 358) ~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 359)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 360) ``struct btf_type`` encoding requirement:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 361) * ``name_off``: offset to a valid C identifier
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 362) * ``info.kind_flag``: 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 363) * ``info.kind``: BTF_KIND_FUNC
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 364) * ``info.vlen``: 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 365) * ``type``: a BTF_KIND_FUNC_PROTO type
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 366)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 367) No additional type data follow ``btf_type``.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 368)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 369) A BTF_KIND_FUNC defines not a type, but a subprogram (function) whose
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 370) signature is defined by ``type``. The subprogram is thus an instance of that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 371) type. The BTF_KIND_FUNC may in turn be referenced by a func_info in the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 372) :ref:`BTF_Ext_Section` (ELF) or in the arguments to :ref:`BPF_Prog_Load`
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 373) (ABI).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 374)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 375) 2.2.13 BTF_KIND_FUNC_PROTO
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 376) ~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 377)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 378) ``struct btf_type`` encoding requirement:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 379) * ``name_off``: 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 380) * ``info.kind_flag``: 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 381) * ``info.kind``: BTF_KIND_FUNC_PROTO
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 382) * ``info.vlen``: # of parameters
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 383) * ``type``: the return type
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 384)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 385) ``btf_type`` is followed by ``info.vlen`` number of ``struct btf_param``.::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 386)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 387) struct btf_param {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 388) __u32 name_off;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 389) __u32 type;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 390) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 391)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 392) If a BTF_KIND_FUNC_PROTO type is referred by a BTF_KIND_FUNC type, then
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 393) ``btf_param.name_off`` must point to a valid C identifier except for the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 394) possible last argument representing the variable argument. The btf_param.type
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 395) refers to parameter type.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 396)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 397) If the function has variable arguments, the last parameter is encoded with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 398) ``name_off = 0`` and ``type = 0``.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 399)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 400) 2.2.14 BTF_KIND_VAR
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 401) ~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 402)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 403) ``struct btf_type`` encoding requirement:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 404) * ``name_off``: offset to a valid C identifier
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 405) * ``info.kind_flag``: 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 406) * ``info.kind``: BTF_KIND_VAR
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 407) * ``info.vlen``: 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 408) * ``type``: the type of the variable
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 409)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 410) ``btf_type`` is followed by a single ``struct btf_variable`` with the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 411) following data::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 412)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 413) struct btf_var {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 414) __u32 linkage;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 415) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 416)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 417) ``struct btf_var`` encoding:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 418) * ``linkage``: currently only static variable 0, or globally allocated
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 419) variable in ELF sections 1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 420)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 421) Not all type of global variables are supported by LLVM at this point.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 422) The following is currently available:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 423)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 424) * static variables with or without section attributes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 425) * global variables with section attributes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 426)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 427) The latter is for future extraction of map key/value type id's from a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 428) map definition.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 429)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 430) 2.2.15 BTF_KIND_DATASEC
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 431) ~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 432)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 433) ``struct btf_type`` encoding requirement:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 434) * ``name_off``: offset to a valid name associated with a variable or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 435) one of .data/.bss/.rodata
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 436) * ``info.kind_flag``: 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 437) * ``info.kind``: BTF_KIND_DATASEC
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 438) * ``info.vlen``: # of variables
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 439) * ``size``: total section size in bytes (0 at compilation time, patched
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 440) to actual size by BPF loaders such as libbpf)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 441)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 442) ``btf_type`` is followed by ``info.vlen`` number of ``struct btf_var_secinfo``.::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 443)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 444) struct btf_var_secinfo {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 445) __u32 type;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 446) __u32 offset;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 447) __u32 size;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 448) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 449)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 450) ``struct btf_var_secinfo`` encoding:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 451) * ``type``: the type of the BTF_KIND_VAR variable
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 452) * ``offset``: the in-section offset of the variable
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 453) * ``size``: the size of the variable in bytes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 454)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 455) 3. BTF Kernel API
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 456) *****************
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 457)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 458) The following bpf syscall command involves BTF:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 459) * BPF_BTF_LOAD: load a blob of BTF data into kernel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 460) * BPF_MAP_CREATE: map creation with btf key and value type info.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 461) * BPF_PROG_LOAD: prog load with btf function and line info.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 462) * BPF_BTF_GET_FD_BY_ID: get a btf fd
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 463) * BPF_OBJ_GET_INFO_BY_FD: btf, func_info, line_info
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 464) and other btf related info are returned.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 465)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 466) The workflow typically looks like:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 467) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 468)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 469) Application:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 470) BPF_BTF_LOAD
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 471) |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 472) v
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 473) BPF_MAP_CREATE and BPF_PROG_LOAD
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 474) |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 475) V
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 476) ......
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 477)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 478) Introspection tool:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 479) ......
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 480) BPF_{PROG,MAP}_GET_NEXT_ID (get prog/map id's)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 481) |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 482) V
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 483) BPF_{PROG,MAP}_GET_FD_BY_ID (get a prog/map fd)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 484) |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 485) V
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 486) BPF_OBJ_GET_INFO_BY_FD (get bpf_prog_info/bpf_map_info with btf_id)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 487) | |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 488) V |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 489) BPF_BTF_GET_FD_BY_ID (get btf_fd) |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 490) | |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 491) V |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 492) BPF_OBJ_GET_INFO_BY_FD (get btf) |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 493) | |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 494) V V
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 495) pretty print types, dump func signatures and line info, etc.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 496)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 497)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 498) 3.1 BPF_BTF_LOAD
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 499) ================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 500)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 501) Load a blob of BTF data into kernel. A blob of data, described in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 502) :ref:`BTF_Type_String`, can be directly loaded into the kernel. A ``btf_fd``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 503) is returned to a userspace.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 504)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 505) 3.2 BPF_MAP_CREATE
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 506) ==================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 507)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 508) A map can be created with ``btf_fd`` and specified key/value type id.::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 509)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 510) __u32 btf_fd; /* fd pointing to a BTF type data */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 511) __u32 btf_key_type_id; /* BTF type_id of the key */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 512) __u32 btf_value_type_id; /* BTF type_id of the value */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 513)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 514) In libbpf, the map can be defined with extra annotation like below:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 515) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 516)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 517) struct bpf_map_def SEC("maps") btf_map = {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 518) .type = BPF_MAP_TYPE_ARRAY,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 519) .key_size = sizeof(int),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 520) .value_size = sizeof(struct ipv_counts),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 521) .max_entries = 4,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 522) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 523) BPF_ANNOTATE_KV_PAIR(btf_map, int, struct ipv_counts);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 524)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 525) Here, the parameters for macro BPF_ANNOTATE_KV_PAIR are map name, key and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 526) value types for the map. During ELF parsing, libbpf is able to extract
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 527) key/value type_id's and assign them to BPF_MAP_CREATE attributes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 528) automatically.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 529)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 530) .. _BPF_Prog_Load:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 531)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 532) 3.3 BPF_PROG_LOAD
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 533) =================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 534)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 535) During prog_load, func_info and line_info can be passed to kernel with proper
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 536) values for the following attributes:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 537) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 538)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 539) __u32 insn_cnt;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 540) __aligned_u64 insns;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 541) ......
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 542) __u32 prog_btf_fd; /* fd pointing to BTF type data */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 543) __u32 func_info_rec_size; /* userspace bpf_func_info size */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 544) __aligned_u64 func_info; /* func info */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 545) __u32 func_info_cnt; /* number of bpf_func_info records */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 546) __u32 line_info_rec_size; /* userspace bpf_line_info size */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 547) __aligned_u64 line_info; /* line info */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 548) __u32 line_info_cnt; /* number of bpf_line_info records */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 549)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 550) The func_info and line_info are an array of below, respectively.::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 551)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 552) struct bpf_func_info {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 553) __u32 insn_off; /* [0, insn_cnt - 1] */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 554) __u32 type_id; /* pointing to a BTF_KIND_FUNC type */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 555) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 556) struct bpf_line_info {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 557) __u32 insn_off; /* [0, insn_cnt - 1] */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 558) __u32 file_name_off; /* offset to string table for the filename */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 559) __u32 line_off; /* offset to string table for the source line */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 560) __u32 line_col; /* line number and column number */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 561) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 562)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 563) func_info_rec_size is the size of each func_info record, and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 564) line_info_rec_size is the size of each line_info record. Passing the record
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 565) size to kernel make it possible to extend the record itself in the future.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 566)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 567) Below are requirements for func_info:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 568) * func_info[0].insn_off must be 0.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 569) * the func_info insn_off is in strictly increasing order and matches
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 570) bpf func boundaries.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 571)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 572) Below are requirements for line_info:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 573) * the first insn in each func must have a line_info record pointing to it.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 574) * the line_info insn_off is in strictly increasing order.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 575)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 576) For line_info, the line number and column number are defined as below:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 577) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 578)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 579) #define BPF_LINE_INFO_LINE_NUM(line_col) ((line_col) >> 10)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 580) #define BPF_LINE_INFO_LINE_COL(line_col) ((line_col) & 0x3ff)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 581)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 582) 3.4 BPF_{PROG,MAP}_GET_NEXT_ID
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 583) ==============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 584)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 585) In kernel, every loaded program, map or btf has a unique id. The id won't
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 586) change during the lifetime of a program, map, or btf.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 587)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 588) The bpf syscall command BPF_{PROG,MAP}_GET_NEXT_ID returns all id's, one for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 589) each command, to user space, for bpf program or maps, respectively, so an
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 590) inspection tool can inspect all programs and maps.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 591)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 592) 3.5 BPF_{PROG,MAP}_GET_FD_BY_ID
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 593) ===============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 594)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 595) An introspection tool cannot use id to get details about program or maps.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 596) A file descriptor needs to be obtained first for reference-counting purpose.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 597)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 598) 3.6 BPF_OBJ_GET_INFO_BY_FD
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 599) ==========================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 600)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 601) Once a program/map fd is acquired, an introspection tool can get the detailed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 602) information from kernel about this fd, some of which are BTF-related. For
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 603) example, ``bpf_map_info`` returns ``btf_id`` and key/value type ids.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 604) ``bpf_prog_info`` returns ``btf_id``, func_info, and line info for translated
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 605) bpf byte codes, and jited_line_info.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 606)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 607) 3.7 BPF_BTF_GET_FD_BY_ID
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 608) ========================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 609)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 610) With ``btf_id`` obtained in ``bpf_map_info`` and ``bpf_prog_info``, bpf
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 611) syscall command BPF_BTF_GET_FD_BY_ID can retrieve a btf fd. Then, with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 612) command BPF_OBJ_GET_INFO_BY_FD, the btf blob, originally loaded into the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 613) kernel with BPF_BTF_LOAD, can be retrieved.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 614)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 615) With the btf blob, ``bpf_map_info``, and ``bpf_prog_info``, an introspection
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 616) tool has full btf knowledge and is able to pretty print map key/values, dump
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 617) func signatures and line info, along with byte/jit codes.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 618)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 619) 4. ELF File Format Interface
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 620) ****************************
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 621)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 622) 4.1 .BTF section
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 623) ================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 624)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 625) The .BTF section contains type and string data. The format of this section is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 626) same as the one describe in :ref:`BTF_Type_String`.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 627)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 628) .. _BTF_Ext_Section:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 629)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 630) 4.2 .BTF.ext section
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 631) ====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 632)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 633) The .BTF.ext section encodes func_info and line_info which needs loader
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 634) manipulation before loading into the kernel.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 635)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 636) The specification for .BTF.ext section is defined at ``tools/lib/bpf/btf.h``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 637) and ``tools/lib/bpf/btf.c``.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 638)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 639) The current header of .BTF.ext section::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 640)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 641) struct btf_ext_header {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 642) __u16 magic;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 643) __u8 version;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 644) __u8 flags;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 645) __u32 hdr_len;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 646)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 647) /* All offsets are in bytes relative to the end of this header */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 648) __u32 func_info_off;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 649) __u32 func_info_len;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 650) __u32 line_info_off;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 651) __u32 line_info_len;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 652) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 653)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 654) It is very similar to .BTF section. Instead of type/string section, it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 655) contains func_info and line_info section. See :ref:`BPF_Prog_Load` for details
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 656) about func_info and line_info record format.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 657)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 658) The func_info is organized as below.::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 659)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 660) func_info_rec_size
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 661) btf_ext_info_sec for section #1 /* func_info for section #1 */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 662) btf_ext_info_sec for section #2 /* func_info for section #2 */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 663) ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 664)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 665) ``func_info_rec_size`` specifies the size of ``bpf_func_info`` structure when
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 666) .BTF.ext is generated. ``btf_ext_info_sec``, defined below, is a collection of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 667) func_info for each specific ELF section.::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 668)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 669) struct btf_ext_info_sec {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 670) __u32 sec_name_off; /* offset to section name */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 671) __u32 num_info;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 672) /* Followed by num_info * record_size number of bytes */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 673) __u8 data[0];
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 674) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 675)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 676) Here, num_info must be greater than 0.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 677)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 678) The line_info is organized as below.::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 679)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 680) line_info_rec_size
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 681) btf_ext_info_sec for section #1 /* line_info for section #1 */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 682) btf_ext_info_sec for section #2 /* line_info for section #2 */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 683) ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 684)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 685) ``line_info_rec_size`` specifies the size of ``bpf_line_info`` structure when
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 686) .BTF.ext is generated.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 687)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 688) The interpretation of ``bpf_func_info->insn_off`` and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 689) ``bpf_line_info->insn_off`` is different between kernel API and ELF API. For
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 690) kernel API, the ``insn_off`` is the instruction offset in the unit of ``struct
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 691) bpf_insn``. For ELF API, the ``insn_off`` is the byte offset from the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 692) beginning of section (``btf_ext_info_sec->sec_name_off``).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 693)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 694) 4.2 .BTF_ids section
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 695) ====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 696)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 697) The .BTF_ids section encodes BTF ID values that are used within the kernel.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 698)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 699) This section is created during the kernel compilation with the help of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 700) macros defined in ``include/linux/btf_ids.h`` header file. Kernel code can
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 701) use them to create lists and sets (sorted lists) of BTF ID values.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 702)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 703) The ``BTF_ID_LIST`` and ``BTF_ID`` macros define unsorted list of BTF ID values,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 704) with following syntax::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 705)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 706) BTF_ID_LIST(list)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 707) BTF_ID(type1, name1)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 708) BTF_ID(type2, name2)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 709)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 710) resulting in following layout in .BTF_ids section::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 711)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 712) __BTF_ID__type1__name1__1:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 713) .zero 4
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 714) __BTF_ID__type2__name2__2:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 715) .zero 4
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 716)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 717) The ``u32 list[];`` variable is defined to access the list.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 718)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 719) The ``BTF_ID_UNUSED`` macro defines 4 zero bytes. It's used when we
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 720) want to define unused entry in BTF_ID_LIST, like::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 721)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 722) BTF_ID_LIST(bpf_skb_output_btf_ids)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 723) BTF_ID(struct, sk_buff)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 724) BTF_ID_UNUSED
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 725) BTF_ID(struct, task_struct)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 726)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 727) The ``BTF_SET_START/END`` macros pair defines sorted list of BTF ID values
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 728) and their count, with following syntax::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 729)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 730) BTF_SET_START(set)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 731) BTF_ID(type1, name1)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 732) BTF_ID(type2, name2)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 733) BTF_SET_END(set)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 734)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 735) resulting in following layout in .BTF_ids section::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 736)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 737) __BTF_ID__set__set:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 738) .zero 4
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 739) __BTF_ID__type1__name1__3:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 740) .zero 4
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 741) __BTF_ID__type2__name2__4:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 742) .zero 4
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 743)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 744) The ``struct btf_id_set set;`` variable is defined to access the list.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 745)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 746) The ``typeX`` name can be one of following::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 747)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 748) struct, union, typedef, func
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 749)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 750) and is used as a filter when resolving the BTF ID value.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 751)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 752) All the BTF ID lists and sets are compiled in the .BTF_ids section and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 753) resolved during the linking phase of kernel build by ``resolve_btfids`` tool.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 754)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 755) 5. Using BTF
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 756) ************
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 757)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 758) 5.1 bpftool map pretty print
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 759) ============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 760)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 761) With BTF, the map key/value can be printed based on fields rather than simply
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 762) raw bytes. This is especially valuable for large structure or if your data
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 763) structure has bitfields. For example, for the following map,::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 764)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 765) enum A { A1, A2, A3, A4, A5 };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 766) typedef enum A ___A;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 767) struct tmp_t {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 768) char a1:4;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 769) int a2:4;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 770) int :4;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 771) __u32 a3:4;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 772) int b;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 773) ___A b1:4;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 774) enum A b2:4;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 775) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 776) struct bpf_map_def SEC("maps") tmpmap = {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 777) .type = BPF_MAP_TYPE_ARRAY,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 778) .key_size = sizeof(__u32),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 779) .value_size = sizeof(struct tmp_t),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 780) .max_entries = 1,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 781) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 782) BPF_ANNOTATE_KV_PAIR(tmpmap, int, struct tmp_t);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 783)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 784) bpftool is able to pretty print like below:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 785) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 786)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 787) [{
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 788) "key": 0,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 789) "value": {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 790) "a1": 0x2,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 791) "a2": 0x4,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 792) "a3": 0x6,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 793) "b": 7,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 794) "b1": 0x8,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 795) "b2": 0xa
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 796) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 797) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 798) ]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 799)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 800) 5.2 bpftool prog dump
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 801) =====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 802)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 803) The following is an example showing how func_info and line_info can help prog
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 804) dump with better kernel symbol names, function prototypes and line
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 805) information.::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 806)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 807) $ bpftool prog dump jited pinned /sys/fs/bpf/test_btf_haskv
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 808) [...]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 809) int test_long_fname_2(struct dummy_tracepoint_args * arg):
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 810) bpf_prog_44a040bf25481309_test_long_fname_2:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 811) ; static int test_long_fname_2(struct dummy_tracepoint_args *arg)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 812) 0: push %rbp
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 813) 1: mov %rsp,%rbp
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 814) 4: sub $0x30,%rsp
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 815) b: sub $0x28,%rbp
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 816) f: mov %rbx,0x0(%rbp)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 817) 13: mov %r13,0x8(%rbp)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 818) 17: mov %r14,0x10(%rbp)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 819) 1b: mov %r15,0x18(%rbp)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 820) 1f: xor %eax,%eax
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 821) 21: mov %rax,0x20(%rbp)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 822) 25: xor %esi,%esi
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 823) ; int key = 0;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 824) 27: mov %esi,-0x4(%rbp)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 825) ; if (!arg->sock)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 826) 2a: mov 0x8(%rdi),%rdi
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 827) ; if (!arg->sock)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 828) 2e: cmp $0x0,%rdi
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 829) 32: je 0x0000000000000070
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 830) 34: mov %rbp,%rsi
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 831) ; counts = bpf_map_lookup_elem(&btf_map, &key);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 832) [...]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 833)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 834) 5.3 Verifier Log
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 835) ================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 836)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 837) The following is an example of how line_info can help debugging verification
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 838) failure.::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 839)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 840) /* The code at tools/testing/selftests/bpf/test_xdp_noinline.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 841) * is modified as below.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 842) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 843) data = (void *)(long)xdp->data;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 844) data_end = (void *)(long)xdp->data_end;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 845) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 846) if (data + 4 > data_end)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 847) return XDP_DROP;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 848) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 849) *(u32 *)data = dst->dst;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 850)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 851) $ bpftool prog load ./test_xdp_noinline.o /sys/fs/bpf/test_xdp_noinline type xdp
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 852) ; data = (void *)(long)xdp->data;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 853) 224: (79) r2 = *(u64 *)(r10 -112)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 854) 225: (61) r2 = *(u32 *)(r2 +0)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 855) ; *(u32 *)data = dst->dst;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 856) 226: (63) *(u32 *)(r2 +0) = r1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 857) invalid access to packet, off=0 size=4, R2(id=0,off=0,r=0)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 858) R2 offset is outside of the packet
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 859)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 860) 6. BTF Generation
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 861) *****************
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 862)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 863) You need latest pahole
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 864)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 865) https://git.kernel.org/pub/scm/devel/pahole/pahole.git/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 866)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 867) or llvm (8.0 or later). The pahole acts as a dwarf2btf converter. It doesn't
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 868) support .BTF.ext and btf BTF_KIND_FUNC type yet. For example,::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 869)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 870) -bash-4.4$ cat t.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 871) struct t {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 872) int a:2;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 873) int b:3;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 874) int c:2;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 875) } g;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 876) -bash-4.4$ gcc -c -O2 -g t.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 877) -bash-4.4$ pahole -JV t.o
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 878) File t.o:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 879) [1] STRUCT t kind_flag=1 size=4 vlen=3
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 880) a type_id=2 bitfield_size=2 bits_offset=0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 881) b type_id=2 bitfield_size=3 bits_offset=2
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 882) c type_id=2 bitfield_size=2 bits_offset=5
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 883) [2] INT int size=4 bit_offset=0 nr_bits=32 encoding=SIGNED
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 884)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 885) The llvm is able to generate .BTF and .BTF.ext directly with -g for bpf target
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 886) only. The assembly code (-S) is able to show the BTF encoding in assembly
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 887) format.::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 888)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 889) -bash-4.4$ cat t2.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 890) typedef int __int32;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 891) struct t2 {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 892) int a2;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 893) int (*f2)(char q1, __int32 q2, ...);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 894) int (*f3)();
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 895) } g2;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 896) int main() { return 0; }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 897) int test() { return 0; }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 898) -bash-4.4$ clang -c -g -O2 -target bpf t2.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 899) -bash-4.4$ readelf -S t2.o
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 900) ......
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 901) [ 8] .BTF PROGBITS 0000000000000000 00000247
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 902) 000000000000016e 0000000000000000 0 0 1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 903) [ 9] .BTF.ext PROGBITS 0000000000000000 000003b5
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 904) 0000000000000060 0000000000000000 0 0 1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 905) [10] .rel.BTF.ext REL 0000000000000000 000007e0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 906) 0000000000000040 0000000000000010 16 9 8
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 907) ......
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 908) -bash-4.4$ clang -S -g -O2 -target bpf t2.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 909) -bash-4.4$ cat t2.s
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 910) ......
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 911) .section .BTF,"",@progbits
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 912) .short 60319 # 0xeb9f
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 913) .byte 1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 914) .byte 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 915) .long 24
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 916) .long 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 917) .long 220
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 918) .long 220
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 919) .long 122
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 920) .long 0 # BTF_KIND_FUNC_PROTO(id = 1)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 921) .long 218103808 # 0xd000000
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 922) .long 2
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 923) .long 83 # BTF_KIND_INT(id = 2)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 924) .long 16777216 # 0x1000000
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 925) .long 4
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 926) .long 16777248 # 0x1000020
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 927) ......
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 928) .byte 0 # string offset=0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 929) .ascii ".text" # string offset=1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 930) .byte 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 931) .ascii "/home/yhs/tmp-pahole/t2.c" # string offset=7
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 932) .byte 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 933) .ascii "int main() { return 0; }" # string offset=33
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 934) .byte 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 935) .ascii "int test() { return 0; }" # string offset=58
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 936) .byte 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 937) .ascii "int" # string offset=83
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 938) ......
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 939) .section .BTF.ext,"",@progbits
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 940) .short 60319 # 0xeb9f
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 941) .byte 1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 942) .byte 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 943) .long 24
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 944) .long 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 945) .long 28
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 946) .long 28
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 947) .long 44
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 948) .long 8 # FuncInfo
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 949) .long 1 # FuncInfo section string offset=1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 950) .long 2
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 951) .long .Lfunc_begin0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 952) .long 3
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 953) .long .Lfunc_begin1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 954) .long 5
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 955) .long 16 # LineInfo
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 956) .long 1 # LineInfo section string offset=1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 957) .long 2
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 958) .long .Ltmp0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 959) .long 7
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 960) .long 33
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 961) .long 7182 # Line 7 Col 14
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 962) .long .Ltmp3
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 963) .long 7
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 964) .long 58
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 965) .long 8206 # Line 8 Col 14
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 966)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 967) 7. Testing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 968) **********
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 969)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 970) Kernel bpf selftest `test_btf.c` provides extensive set of BTF-related tests.
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags