On 5/17/22 4:47 PM, Andrii Nakryiko wrote:
On Fri, May 13, 2022 at 8:14 PM Yonghong Song <yhs@xxxxxx> wrote:
Add BTF_KIND_ENUM64 documentation in btf.rst.
Also fixed a typo for section number for BTF_KIND_TYPE_TAG
from 2.2.17 to 2.2.18.
Signed-off-by: Yonghong Song <yhs@xxxxxx>
---
LGTM, but see pedantic note below
Acked-by: Andrii Nakryiko <andrii@xxxxxxxxxx>
Documentation/bpf/btf.rst | 34 +++++++++++++++++++++++++++++-----
1 file changed, 29 insertions(+), 5 deletions(-)
[...]
+2.2.19 BTF_KIND_ENUM64
+~~~~~~~~~~~~~~~~~~~~~~
+
+``struct btf_type`` encoding requirement:
+ * ``name_off``: 0 or offset to a valid C identifier
+ * ``info.kind_flag``: 0 for unsigned, 1 for signed
+ * ``info.kind``: BTF_KIND_ENUM64
+ * ``info.vlen``: number of enum values
+ * ``size``: 1/2/4/8
+
+``btf_type`` is followed by ``info.vlen`` number of ``struct btf_enum64``.::
+
+ struct btf_enum64 {
+ __u32 name_off;
+ __u32 val_lo32;
+ __u32 val_hi32;
+ };
+
+The ``btf_enum64`` encoding:
+ * ``name_off``: offset to a valid C identifier
+ * ``val_lo32``: lower 32-bit value for a 64-bit value
+ * ``val_hi32``: high 32-bit value for a 64-bit value
+
I presume if size is < 8 then val_hi32 will be sign-extended (i.e.,
0xffffffff for signed enum and negative enumerator values, 0
otherwise), right? Should it be specified here?
Right. This is similar to btf_enum, e.g., btf_enum can have size 1,
e.g.
enum T { A = -1, B, C, D } __attribute__((packed));
But for enumerator A, its value will be 0xffffffff.
Here, val_lo32 and val_hi32 are just low and high 32bits
of unsigned long long value of the enumerator. I will add
a few sentences to clarify here.
3. BTF Kernel API
=================
--
2.30.2
