Message ID | 20210308235913.162038-1-iii@linux.ibm.com (mailing list archive) |
---|---|
State | Superseded |
Delegated to: | BPF |
Headers | show |
Series | [dwarves,v2] btf: Add support for the floating-point types | expand |
Context | Check | Description |
---|---|---|
netdev/tree_selection | success | Not a local patch |
Em Tue, Mar 09, 2021 at 12:59:13AM +0100, Ilya Leoshkevich escreveu: > Some BPF programs compiled on s390 fail to load, because s390 > arch-specific linux headers contain float and double types. > > Fix as follows: > > - Make the DWARF loader fill base_type.float_type. > > - Introduce libbpf compatibility level command-line parameter, so that > pahole could be used to build both the older and the newer kernels. > > - libbpf introduced the support for the floating-point types in commit > 986962fade5, so update the libbpf submodule to that version and use > the new btf__add_float() function in order to emit the floating-point > types when not in the compatibility mode and base_type.float_type is > set. > > - Make the BTF loader recognize the new BTF kind. > > Example of the resulting entry in the vmlinux BTF: > > [7164] FLOAT 'double' size=8 > > when building with: > > LLVM_OBJCOPY=${OBJCOPY} ${PAHOLE} -J ${1} --libbpf_compat=0.4.0 I'm testing it now, and added as a followup patch the man page entry, please check that the wording is appropriate. Thanks, - Arnaldo [acme@five pahole]$ vim man-pages/pahole.1 [acme@five pahole]$ git diff diff --git a/man-pages/pahole.1 b/man-pages/pahole.1 index 352bb5e45f319da4..787771753d1933b1 100644 --- a/man-pages/pahole.1 +++ b/man-pages/pahole.1 @@ -199,6 +199,12 @@ Path to the base BTF file, for instance: vmlinux when encoding kernel module BTF This may be inferred when asking for a /sys/kernel/btf/MODULE, when it will be autoconfigured to "/sys/kernel/btf/vmlinux". +.TP +.B \-\-libbpf_compat=LIBBPF_VERSION +Produce output compatible with this libbpf version. For instance, specifying 0.4.0 as +the version would encode BTF_KIND_FLOAT entries in systems where the vmlinux DWARF +information has float types. + .TP .B \-l, \-\-show_first_biggest_size_base_type_member Show first biggest size base_type member. [acme@five pahole]$
On Tue, 2021-03-09 at 08:48 -0300, Arnaldo Carvalho de Melo wrote: > Em Tue, Mar 09, 2021 at 12:59:13AM +0100, Ilya Leoshkevich escreveu: > > Some BPF programs compiled on s390 fail to load, because s390 > > arch-specific linux headers contain float and double types. > > > > Fix as follows: > > > > - Make the DWARF loader fill base_type.float_type. > > > > - Introduce libbpf compatibility level command-line parameter, so > > that > > pahole could be used to build both the older and the newer > > kernels. > > > > - libbpf introduced the support for the floating-point types in > > commit > > 986962fade5, so update the libbpf submodule to that version and > > use > > the new btf__add_float() function in order to emit the floating- > > point > > types when not in the compatibility mode and base_type.float_type > > is > > set. > > > > - Make the BTF loader recognize the new BTF kind. > > > > Example of the resulting entry in the vmlinux BTF: > > > > [7164] FLOAT 'double' size=8 > > > > when building with: > > > > LLVM_OBJCOPY=${OBJCOPY} ${PAHOLE} -J ${1} --libbpf_compat=0.4.0 > > I'm testing it now, and added as a followup patch the man page entry, > please check that the wording is appropriate. > > Thanks, > > - Arnaldo > > [acme@five pahole]$ vim man-pages/pahole.1 > [acme@five pahole]$ git diff > diff --git a/man-pages/pahole.1 b/man-pages/pahole.1 > index 352bb5e45f319da4..787771753d1933b1 100644 > --- a/man-pages/pahole.1 > +++ b/man-pages/pahole.1 > @@ -199,6 +199,12 @@ Path to the base BTF file, for instance: vmlinux > when encoding kernel module BTF > This may be inferred when asking for a /sys/kernel/btf/MODULE, when > it will be autoconfigured > to "/sys/kernel/btf/vmlinux". > > +.TP > +.B \-\-libbpf_compat=LIBBPF_VERSION > +Produce output compatible with this libbpf version. For instance, > specifying 0.4.0 as > +the version would encode BTF_KIND_FLOAT entries in systems where the > vmlinux DWARF > +information has float types. > + > .TP > .B \-l, \-\-show_first_biggest_size_base_type_member > Show first biggest size base_type member. > [acme@five pahole]$ The wording matches what I had in mind for this new flag, thanks!
On Tue, Mar 9, 2021 at 3:48 AM Arnaldo Carvalho de Melo <acme@kernel.org> wrote: > > Em Tue, Mar 09, 2021 at 12:59:13AM +0100, Ilya Leoshkevich escreveu: > > Some BPF programs compiled on s390 fail to load, because s390 > > arch-specific linux headers contain float and double types. > > > > Fix as follows: > > > > - Make the DWARF loader fill base_type.float_type. > > > > - Introduce libbpf compatibility level command-line parameter, so that > > pahole could be used to build both the older and the newer kernels. > > > > - libbpf introduced the support for the floating-point types in commit > > 986962fade5, so update the libbpf submodule to that version and use > > the new btf__add_float() function in order to emit the floating-point > > types when not in the compatibility mode and base_type.float_type is > > set. > > > > - Make the BTF loader recognize the new BTF kind. > > > > Example of the resulting entry in the vmlinux BTF: > > > > [7164] FLOAT 'double' size=8 > > > > when building with: > > > > LLVM_OBJCOPY=${OBJCOPY} ${PAHOLE} -J ${1} --libbpf_compat=0.4.0 > > I'm testing it now, and added as a followup patch the man page entry, > please check that the wording is appropriate. > > Thanks, > > - Arnaldo > > [acme@five pahole]$ vim man-pages/pahole.1 > [acme@five pahole]$ git diff > diff --git a/man-pages/pahole.1 b/man-pages/pahole.1 > index 352bb5e45f319da4..787771753d1933b1 100644 > --- a/man-pages/pahole.1 > +++ b/man-pages/pahole.1 > @@ -199,6 +199,12 @@ Path to the base BTF file, for instance: vmlinux when encoding kernel module BTF > This may be inferred when asking for a /sys/kernel/btf/MODULE, when it will be autoconfigured > to "/sys/kernel/btf/vmlinux". > > +.TP > +.B \-\-libbpf_compat=LIBBPF_VERSION > +Produce output compatible with this libbpf version. For instance, specifying 0.4.0 as > +the version would encode BTF_KIND_FLOAT entries in systems where the vmlinux DWARF > +information has float types. TBH, I think it's not exactly right to call out libbpf version here. It's BTF "version" (if we had such a thing) that determines the set of supported BTF kinds. There could be other libraries that might want to parse BTF. So I don't know what this should be called, but libbpf_compat is probably a wrong name for it. If we do want to teach pahole to not emit some parts of BTF, it should probably be a set of BPF features, not some arbitrary library versions. > + > .TP > .B \-l, \-\-show_first_biggest_size_base_type_member > Show first biggest size base_type member. > [acme@five pahole]$
On Tue, 2021-03-09 at 13:37 -0800, Andrii Nakryiko wrote: > On Tue, Mar 9, 2021 at 3:48 AM Arnaldo Carvalho de Melo < > acme@kernel.org> wrote: > > > > Em Tue, Mar 09, 2021 at 12:59:13AM +0100, Ilya Leoshkevich > > escreveu: > > > Some BPF programs compiled on s390 fail to load, because s390 > > > arch-specific linux headers contain float and double types. > > > > > > Fix as follows: > > > > > > - Make the DWARF loader fill base_type.float_type. > > > > > > - Introduce libbpf compatibility level command-line parameter, so > > > that > > > pahole could be used to build both the older and the newer > > > kernels. > > > > > > - libbpf introduced the support for the floating-point types in > > > commit > > > 986962fade5, so update the libbpf submodule to that version and > > > use > > > the new btf__add_float() function in order to emit the > > > floating-point > > > types when not in the compatibility mode and > > > base_type.float_type is > > > set. > > > > > > - Make the BTF loader recognize the new BTF kind. > > > > > > Example of the resulting entry in the vmlinux BTF: > > > > > > [7164] FLOAT 'double' size=8 > > > > > > when building with: > > > > > > LLVM_OBJCOPY=${OBJCOPY} ${PAHOLE} -J ${1} -- > > > libbpf_compat=0.4.0 > > > > I'm testing it now, and added as a followup patch the man page > > entry, > > please check that the wording is appropriate. > > > > Thanks, > > > > - Arnaldo > > > > [acme@five pahole]$ vim man-pages/pahole.1 > > [acme@five pahole]$ git diff > > diff --git a/man-pages/pahole.1 b/man-pages/pahole.1 > > index 352bb5e45f319da4..787771753d1933b1 100644 > > --- a/man-pages/pahole.1 > > +++ b/man-pages/pahole.1 > > @@ -199,6 +199,12 @@ Path to the base BTF file, for instance: > > vmlinux when encoding kernel module BTF > > This may be inferred when asking for a /sys/kernel/btf/MODULE, > > when it will be autoconfigured > > to "/sys/kernel/btf/vmlinux". > > > > +.TP > > +.B \-\-libbpf_compat=LIBBPF_VERSION > > +Produce output compatible with this libbpf version. For instance, > > specifying 0.4.0 as > > +the version would encode BTF_KIND_FLOAT entries in systems where > > the vmlinux DWARF > > +information has float types. > > TBH, I think it's not exactly right to call out libbpf version here. > It's BTF "version" (if we had such a thing) that determines the set > of > supported BTF kinds. There could be other libraries that might want > to > parse BTF. So I don't know what this should be called, but > libbpf_compat is probably a wrong name for it. BTF version seems to exist: btf_header.version. Should we maybe bump this? > > If we do want to teach pahole to not emit some parts of BTF, it > should > probably be a set of BPF features, not some arbitrary library > versions. I thought about just adding --btf-allow-floats, but if new features will be added in the future, the list of options will become unwieldy. So I thought it would be good to settle for something that increases monotonically.
On Tue, Mar 9, 2021 at 1:57 PM Ilya Leoshkevich <iii@linux.ibm.com> wrote: > > On Tue, 2021-03-09 at 13:37 -0800, Andrii Nakryiko wrote: > > On Tue, Mar 9, 2021 at 3:48 AM Arnaldo Carvalho de Melo < > > acme@kernel.org> wrote: > > > > > > Em Tue, Mar 09, 2021 at 12:59:13AM +0100, Ilya Leoshkevich > > > escreveu: > > > > Some BPF programs compiled on s390 fail to load, because s390 > > > > arch-specific linux headers contain float and double types. > > > > > > > > Fix as follows: > > > > > > > > - Make the DWARF loader fill base_type.float_type. > > > > > > > > - Introduce libbpf compatibility level command-line parameter, so > > > > that > > > > pahole could be used to build both the older and the newer > > > > kernels. > > > > > > > > - libbpf introduced the support for the floating-point types in > > > > commit > > > > 986962fade5, so update the libbpf submodule to that version and > > > > use > > > > the new btf__add_float() function in order to emit the > > > > floating-point > > > > types when not in the compatibility mode and > > > > base_type.float_type is > > > > set. > > > > > > > > - Make the BTF loader recognize the new BTF kind. > > > > > > > > Example of the resulting entry in the vmlinux BTF: > > > > > > > > [7164] FLOAT 'double' size=8 > > > > > > > > when building with: > > > > > > > > LLVM_OBJCOPY=${OBJCOPY} ${PAHOLE} -J ${1} -- > > > > libbpf_compat=0.4.0 > > > > > > I'm testing it now, and added as a followup patch the man page > > > entry, > > > please check that the wording is appropriate. > > > > > > Thanks, > > > > > > - Arnaldo > > > > > > [acme@five pahole]$ vim man-pages/pahole.1 > > > [acme@five pahole]$ git diff > > > diff --git a/man-pages/pahole.1 b/man-pages/pahole.1 > > > index 352bb5e45f319da4..787771753d1933b1 100644 > > > --- a/man-pages/pahole.1 > > > +++ b/man-pages/pahole.1 > > > @@ -199,6 +199,12 @@ Path to the base BTF file, for instance: > > > vmlinux when encoding kernel module BTF > > > This may be inferred when asking for a /sys/kernel/btf/MODULE, > > > when it will be autoconfigured > > > to "/sys/kernel/btf/vmlinux". > > > > > > +.TP > > > +.B \-\-libbpf_compat=LIBBPF_VERSION > > > +Produce output compatible with this libbpf version. For instance, > > > specifying 0.4.0 as > > > +the version would encode BTF_KIND_FLOAT entries in systems where > > > the vmlinux DWARF > > > +information has float types. > > > > TBH, I think it's not exactly right to call out libbpf version here. > > It's BTF "version" (if we had such a thing) that determines the set > > of > > supported BTF kinds. There could be other libraries that might want > > to > > parse BTF. So I don't know what this should be called, but > > libbpf_compat is probably a wrong name for it. > > BTF version seems to exist: btf_header.version. Should we maybe bump > this? That seems excessive. If the kernel doesn't use FLOATs, then no one would even notice a difference. While if we bump this version, then everything will automatically become incompatible. > > > > > If we do want to teach pahole to not emit some parts of BTF, it > > should > > probably be a set of BPF features, not some arbitrary library > > versions. > > I thought about just adding --btf-allow-floats, but if new features > will be added in the future, the list of options will become unwieldy. > So I thought it would be good to settle for something that increases > monotonically. > BTF_KIND_FLOAT is the first extension in a long while. I'd worry about the proliferation of new options when we actually see some proof of that being a problem in practice.
Em Tue, Mar 09, 2021 at 08:14:50PM -0800, Andrii Nakryiko escreveu: > On Tue, Mar 9, 2021 at 1:57 PM Ilya Leoshkevich <iii@linux.ibm.com> wrote: > > On Tue, 2021-03-09 at 13:37 -0800, Andrii Nakryiko wrote: > > > On Tue, Mar 9, 2021 at 3:48 AM Arnaldo Carvalho de Melo <acme@kernel.org> wrote: > > > > Em Tue, Mar 09, 2021 at 12:59:13AM +0100, Ilya Leoshkevich escreveu: > > > TBH, I think it's not exactly right to call out libbpf version > > > here. It's BTF "version" (if we had such a thing) that determines > > > the set of supported BTF kinds. There could be other libraries > > > that might want to parse BTF. So I don't know what this should be > > > called, but libbpf_compat is probably a wrong name for it. > > BTF version seems to exist: btf_header.version. Should we maybe bump > > this? > That seems excessive. If the kernel doesn't use FLOATs, then no one > would even notice a difference. While if we bump this version, then > everything will automatically become incompatible. > > > If we do want to teach pahole to not emit some parts of BTF, it > > > should > > > probably be a set of BPF features, not some arbitrary library > > > versions. > > I thought about just adding --btf-allow-floats, but if new features > > will be added in the future, the list of options will become unwieldy. > > So I thought it would be good to settle for something that increases > > monotonically. > BTF_KIND_FLOAT is the first extension in a long while. I'd worry about > the proliferation of new options when we actually see some proof of > that being a problem in practice. I tend to agree, Ilya, can you rework the patch in that direction? Something like --encode-btf-kind-float that starts disabled or other suitable name? - Arnaldo
On Wed, 2021-03-10 at 10:37 -0300, Arnaldo Carvalho de Melo wrote: > Em Tue, Mar 09, 2021 at 08:14:50PM -0800, Andrii Nakryiko escreveu: > > On Tue, Mar 9, 2021 at 1:57 PM Ilya Leoshkevich <iii@linux.ibm.com> > > wrote: > > > On Tue, 2021-03-09 at 13:37 -0800, Andrii Nakryiko wrote: > > > > On Tue, Mar 9, 2021 at 3:48 AM Arnaldo Carvalho de Melo > > > > <acme@kernel.org> wrote: > > > > > Em Tue, Mar 09, 2021 at 12:59:13AM +0100, Ilya Leoshkevich > > > > > escreveu: > > > > TBH, I think it's not exactly right to call out libbpf version > > > > here. It's BTF "version" (if we had such a thing) that > > > > determines > > > > the set of supported BTF kinds. There could be other libraries > > > > that might want to parse BTF. So I don't know what this should > > > > be > > > > called, but libbpf_compat is probably a wrong name for it. > > > > BTF version seems to exist: btf_header.version. Should we maybe > > > bump > > > this? > > > That seems excessive. If the kernel doesn't use FLOATs, then no one > > would even notice a difference. While if we bump this version, then > > everything will automatically become incompatible. > > > > > If we do want to teach pahole to not emit some parts of BTF, it > > > > should > > > > probably be a set of BPF features, not some arbitrary library > > > > versions. > > > > I thought about just adding --btf-allow-floats, but if new > > > features > > > will be added in the future, the list of options will become > > > unwieldy. > > > So I thought it would be good to settle for something that > > > increases > > > monotonically. > > > BTF_KIND_FLOAT is the first extension in a long while. I'd worry > > about > > the proliferation of new options when we actually see some proof of > > that being a problem in practice. > > I tend to agree, Ilya, can you rework the patch in that direction? > Something like --encode-btf-kind-float that starts disabled or other > suitable name? > > - Arnaldo Sure, I'm actually testing v3 that does this right now. So far I went with simply --btf_float, but I'll change it to the more explicit --encode_btf_kind_float.
diff --git a/btf_loader.c b/btf_loader.c index ec286f4..7cc39aa 100644 --- a/btf_loader.c +++ b/btf_loader.c @@ -160,7 +160,7 @@ static struct variable *variable__new(strings_t name, uint32_t linkage) return var; } -static int create_new_base_type(struct btf_elf *btfe, const struct btf_type *tp, uint32_t id) +static int create_new_int_type(struct btf_elf *btfe, const struct btf_type *tp, uint32_t id) { uint32_t attrs = btf_int_encoding(tp); strings_t name = tp->name_off; @@ -175,6 +175,20 @@ static int create_new_base_type(struct btf_elf *btfe, const struct btf_type *tp, return 0; } +static int create_new_float_type(struct btf_elf *btfe, const struct btf_type *tp, uint32_t id) +{ + strings_t name = tp->name_off; + struct base_type *base = base_type__new(name, 0, BT_FP_SINGLE, tp->size * 8); + + if (base == NULL) + return -ENOMEM; + + base->tag.tag = DW_TAG_base_type; + cu__add_tag_with_id(btfe->priv, &base->tag, id); + + return 0; +} + static int create_new_array(struct btf_elf *btfe, const struct btf_type *tp, uint32_t id) { struct btf_array *ap = btf_array(tp); @@ -397,7 +411,7 @@ static int btf_elf__load_types(struct btf_elf *btfe) switch (type) { case BTF_KIND_INT: - err = create_new_base_type(btfe, type_ptr, type_index); + err = create_new_int_type(btfe, type_ptr, type_index); break; case BTF_KIND_ARRAY: err = create_new_array(btfe, type_ptr, type_index); @@ -442,6 +456,9 @@ static int btf_elf__load_types(struct btf_elf *btfe) // BTF_KIND_FUNC corresponding to a defined subprogram. err = create_new_function(btfe, type_ptr, type_index); break; + case BTF_KIND_FLOAT: + err = create_new_float_type(btfe, type_ptr, type_index); + break; default: fprintf(stderr, "BTF: idx: %d, Unknown kind %d\n", type_index, type); fflush(stderr); diff --git a/dwarf_loader.c b/dwarf_loader.c index b73d786..c5e6681 100644 --- a/dwarf_loader.c +++ b/dwarf_loader.c @@ -461,6 +461,16 @@ static struct ptr_to_member_type *ptr_to_member_type__new(Dwarf_Die *die, return ptr; } +static uint8_t encoding_to_float_type(uint64_t encoding) +{ + switch (encoding) { + case DW_ATE_complex_float: return BT_FP_CMPLX; + case DW_ATE_float: return BT_FP_SINGLE; + case DW_ATE_imaginary_float: return BT_FP_IMGRY; + default: return 0; + } +} + static struct base_type *base_type__new(Dwarf_Die *die, struct cu *cu) { struct base_type *bt = tag__alloc(cu, sizeof(*bt)); @@ -474,6 +484,7 @@ static struct base_type *base_type__new(Dwarf_Die *die, struct cu *cu) bt->is_signed = encoding == DW_ATE_signed; bt->is_varargs = false; bt->name_has_encoding = true; + bt->float_type = encoding_to_float_type(encoding); } return bt; diff --git a/lib/bpf b/lib/bpf index 5af3d86..986962f 160000 --- a/lib/bpf +++ b/lib/bpf @@ -1 +1 @@ -Subproject commit 5af3d86b5a2c5fecdc3ab83822d083edd32b4396 +Subproject commit 986962fade5dfa89c2890f3854eb040d2a64ab38 diff --git a/libbtf.c b/libbtf.c index 9f76283..c8a1dc1 100644 --- a/libbtf.c +++ b/libbtf.c @@ -30,6 +30,7 @@ struct btf *base_btf; uint8_t btf_elf__verbose; uint8_t btf_elf__force; +int libbpf_compat = LIBBPF_COMPAT_MIN; static int btf_var_secinfo_cmp(const void *a, const void *b) { @@ -227,6 +228,7 @@ static const char * const btf_kind_str[NR_BTF_KINDS] = { [BTF_KIND_FUNC_PROTO] = "FUNC_PROTO", [BTF_KIND_VAR] = "VAR", [BTF_KIND_DATASEC] = "DATASEC", + [BTF_KIND_FLOAT] = "FLOAT", }; static const char *btf_elf__printable_name(const struct btf_elf *btfe, uint32_t offset) @@ -367,6 +369,27 @@ static void btf_log_func_param(const struct btf_elf *btfe, } } +static int32_t btf_elf__add_float_type(struct btf_elf *btfe, + const struct base_type *bt, + const char *name) +{ + int32_t id; + + id = btf__add_float(btfe->btf, name, BITS_ROUNDUP_BYTES(bt->bit_size)); + if (id < 0) { + btf_elf__log_err(btfe, BTF_KIND_FLOAT, name, true, "Error emitting BTF type"); + } else { + const struct btf_type *t; + + t = btf__type_by_id(btfe->btf, id); + btf_elf__log_type(btfe, t, false, true, + "size=%u nr_bits=%u", + t->size, bt->bit_size); + } + + return id; +} + int32_t btf_elf__add_base_type(struct btf_elf *btfe, const struct base_type *bt, const char *name) { @@ -379,8 +402,17 @@ int32_t btf_elf__add_base_type(struct btf_elf *btfe, const struct base_type *bt, encoding = BTF_INT_SIGNED; } else if (bt->is_bool) { encoding = BTF_INT_BOOL; - } else if (bt->float_type) { - fprintf(stderr, "float_type is not supported\n"); + } else if (bt->float_type && libbpf_compat >= LIBBPF_COMPAT_FLOAT) { + /* + * Encode floats using libbpf. In compatibility mode, encode + * them as ints - that's not fully correct, but that's what it + * used to be. + */ + if (bt->float_type == BT_FP_SINGLE || + bt->float_type == BT_FP_DOUBLE || + bt->float_type == BT_FP_LDBL) + return btf_elf__add_float_type(btfe, bt, name); + fprintf(stderr, "Complex, interval and imaginary float types are not supported\n"); return -1; } diff --git a/libbtf.h b/libbtf.h index 191f586..9fe42be 100644 --- a/libbtf.h +++ b/libbtf.h @@ -36,6 +36,14 @@ extern uint8_t btf_elf__verbose; extern uint8_t btf_elf__force; #define btf_elf__verbose_log(fmt, ...) { if (btf_elf__verbose) printf(fmt, __VA_ARGS__); } +/* DEBUG_INFO_BTF was added in Linux 5.2, which corresponds to libbpf 0.0.3. */ +#define LIBBPF_COMPAT_MIN 0x000003 + +/* The floating-point types were added in libbpf 0.4.0. */ +#define LIBBPF_COMPAT_FLOAT 0x000400 + +extern int libbpf_compat; + #define PERCPU_SECTION ".data..percpu" struct cu; diff --git a/pahole.c b/pahole.c index 4a34ba5..74d2cbb 100644 --- a/pahole.c +++ b/pahole.c @@ -825,6 +825,7 @@ ARGP_PROGRAM_VERSION_HOOK_DEF = dwarves_print_version; #define ARGP_just_packed_structs 319 #define ARGP_numeric_version 320 #define ARGP_btf_base 321 +#define ARGP_libbpf_compat 322 static const struct argp_option pahole__options[] = { { @@ -1119,6 +1120,12 @@ static const struct argp_option pahole__options[] = { .key = ARGP_btf_encode_force, .doc = "Ignore those symbols found invalid when encoding BTF." }, + { + .name = "libbpf_compat", + .key = ARGP_libbpf_compat, + .arg = "LIBBPF_VERSION", + .doc = "Produce output compatible with this libbpf version." + }, { .name = "structs", .key = ARGP_just_structs, @@ -1144,6 +1151,23 @@ static const struct argp_option pahole__options[] = { } }; +static int parse_version(char *arg) +{ + int version, patchlevel = 0, extraversion = 0; + char *dot; + + version = atoi(arg); + dot = strchr(arg, '.'); + if (dot) { + patchlevel = atoi(dot + 1); + dot = strchr(dot + 1, '.'); + if (dot) + extraversion = atoi(dot + 1); + } + + return (version << 16) | (patchlevel << 8) | extraversion; +} + static error_t pahole__options_parser(int key, char *arg, struct argp_state *state) { @@ -1254,6 +1278,8 @@ static error_t pahole__options_parser(int key, char *arg, base_btf_file = arg; break; case ARGP_numeric_version: print_numeric_version = true; break; + case ARGP_libbpf_compat: + libbpf_compat = parse_version(arg); break; default: return ARGP_ERR_UNKNOWN; }
Some BPF programs compiled on s390 fail to load, because s390 arch-specific linux headers contain float and double types. Fix as follows: - Make the DWARF loader fill base_type.float_type. - Introduce libbpf compatibility level command-line parameter, so that pahole could be used to build both the older and the newer kernels. - libbpf introduced the support for the floating-point types in commit 986962fade5, so update the libbpf submodule to that version and use the new btf__add_float() function in order to emit the floating-point types when not in the compatibility mode and base_type.float_type is set. - Make the BTF loader recognize the new BTF kind. Example of the resulting entry in the vmlinux BTF: [7164] FLOAT 'double' size=8 when building with: LLVM_OBJCOPY=${OBJCOPY} ${PAHOLE} -J ${1} --libbpf_compat=0.4.0 Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> --- v1: https://lore.kernel.org/dwarves/20210306022203.152930-1-iii@linux.ibm.com/ v1 -> v2: Introduce libbpf compatibility level command-line parameter. The code should now work for both bpf-next/master and v5.12-rc2. btf_loader.c | 21 +++++++++++++++++++-- dwarf_loader.c | 11 +++++++++++ lib/bpf | 2 +- libbtf.c | 36 ++++++++++++++++++++++++++++++++++-- libbtf.h | 8 ++++++++ pahole.c | 26 ++++++++++++++++++++++++++ 6 files changed, 99 insertions(+), 5 deletions(-)