BPF List
 help / color / mirror / Atom feed
From: Yonghong Song <yhs@fb.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: bpf <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>,
	Andrii Nakryiko <andrii@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Kernel Team <kernel-team@fb.com>
Subject: Re: [PATCH bpf-next v2 10/18] libbpf: Add enum64 relocation support
Date: Wed, 18 May 2022 14:09:53 -0700	[thread overview]
Message-ID: <a5976134-3e16-94ea-fd7b-1053b83747a4@fb.com> (raw)
In-Reply-To: <CAEf4BzarwX0idepo1nA8QvyirRYQ-hZL3ZxKh3H=HWP=8P-=LQ@mail.gmail.com>



On 5/17/22 4:32 PM, Andrii Nakryiko wrote:
> On Fri, May 13, 2022 at 8:13 PM Yonghong Song <yhs@fb.com> wrote:
>>
>> The enum64 relocation support is added. The bpf local type
>> could be either enum or enum64 and the remote type could be
>> either enum or enum64 too. The all combinations of local enum/enum64
>> and remote enum/enum64 are supported.
>>
>> Signed-off-by: Yonghong Song <yhs@fb.com>
>> ---
>>   tools/lib/bpf/btf.h       |  7 ++++++
>>   tools/lib/bpf/libbpf.c    |  7 +++---
>>   tools/lib/bpf/relo_core.c | 49 ++++++++++++++++++++++++++-------------
>>   3 files changed, 44 insertions(+), 19 deletions(-)
>>
> 
> [...]
> 
>>          memset(targ_spec, 0, sizeof(*targ_spec));
>>          targ_spec->btf = targ_btf;
>> @@ -494,18 +498,22 @@ static int bpf_core_spec_match(struct bpf_core_spec *local_spec,
>>
>>          if (core_relo_is_enumval_based(local_spec->relo_kind)) {
>>                  size_t local_essent_len, targ_essent_len;
>> -               const struct btf_enum *e;
>>                  const char *targ_name;
>>
>>                  /* has to resolve to an enum */
>>                  targ_type = skip_mods_and_typedefs(targ_spec->btf, targ_id, &targ_id);
>> -               if (!btf_is_enum(targ_type))
>> +               if (!btf_type_is_any_enum(targ_type))
> 
> just noticed this discrepancy, can you please rename
> s/btf_type_is_any_enum/btf_is_any_enum/ so it's consistent with
> btf_is_enum and btf_is_enum64?

okay.

> 
>>                          return 0;
>>
>>                  local_essent_len = bpf_core_essential_name_len(local_acc->name);
>>
>> -               for (i = 0, e = btf_enum(targ_type); i < btf_vlen(targ_type); i++, e++) {
>> -                       targ_name = btf__name_by_offset(targ_spec->btf, e->name_off);
>> +               for (i = 0; i < btf_vlen(targ_type); i++) {
>> +                       if (btf_is_enum(targ_type))
>> +                               name_off = btf_enum(targ_type)[i].name_off;
>> +                       else
>> +                               name_off = btf_enum64(targ_type)[i].name_off;
>> +
>> +                       targ_name = btf__name_by_offset(targ_spec->btf, name_off);
>>                          targ_essent_len = bpf_core_essential_name_len(targ_name);
>>                          if (targ_essent_len != local_essent_len)
>>                                  continue;
>> @@ -681,7 +689,7 @@ static int bpf_core_calc_field_relo(const char *prog_name,
>>                  break;
>>          case BPF_CORE_FIELD_SIGNED:
>>                  /* enums will be assumed unsigned */
> 
> we don't have to assume anymore, right? let's use kflag for btf_is_any_enum()?

old comment is not accurate any more, will remove.

> 
>> -               *val = btf_is_enum(mt) ||
>> +               *val = btf_type_is_any_enum(mt) ||
>>                         (btf_int_encoding(mt) & BTF_INT_SIGNED);
>>                  if (validate)
>>                          *validate = true; /* signedness is never ambiguous */
> 
> [...]
> 
>> @@ -1089,10 +1097,19 @@ int bpf_core_format_spec(char *buf, size_t buf_sz, const struct bpf_core_spec *s
>>
>>          if (core_relo_is_enumval_based(spec->relo_kind)) {
>>                  t = skip_mods_and_typedefs(spec->btf, type_id, NULL);
>> -               e = btf_enum(t) + spec->raw_spec[0];
>> -               s = btf__name_by_offset(spec->btf, e->name_off);
>> +               if (btf_is_enum(t)) {
>> +                       const struct btf_enum *e;
>>
>> -               append_buf("::%s = %u", s, e->val);
>> +                       e = btf_enum(t) + spec->raw_spec[0];
>> +                       s = btf__name_by_offset(spec->btf, e->name_off);
>> +                       append_buf("::%s = %u", s, e->val);
>> +               } else {
>> +                       const struct btf_enum64 *e;
>> +
>> +                       e = btf_enum64(t) + spec->raw_spec[0];
>> +                       s = btf__name_by_offset(spec->btf, e->name_off);
>> +                       append_buf("::%s = %llu", s, btf_enum64_value(e));
> 
> nit: we do have a sign bit now, so maybe let's print %lld or %llu
> (same for %d and %u above)? btw, please cast (unsigned long long) here

will do.

> 
>> +               }
>>                  return len;
>>          }
>>
>> --
>> 2.30.2
>>

  reply	other threads:[~2022-05-18 21:10 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-14  3:12 [PATCH bpf-next v2 00/18] bpf: Add 64bit enum value support Yonghong Song
2022-05-14  3:12 ` [PATCH bpf-next v2 01/18] bpf: Add btf enum64 support Yonghong Song
2022-05-17  0:06   ` Andrii Nakryiko
2022-05-14  3:12 ` [PATCH bpf-next v2 02/18] libbpf: Permit 64bit relocation value Yonghong Song
2022-05-17  0:08   ` Andrii Nakryiko
2022-05-14  3:12 ` [PATCH bpf-next v2 03/18] libbpf: Fix an error in 64bit relocation value computation Yonghong Song
2022-05-17  0:10   ` Andrii Nakryiko
2022-05-14  3:12 ` [PATCH bpf-next v2 04/18] libbpf: Refactor btf__add_enum() for future code sharing Yonghong Song
2022-05-17  0:15   ` Andrii Nakryiko
2022-05-14  3:12 ` [PATCH bpf-next v2 05/18] libbpf: Add enum64 parsing and new enum64 public API Yonghong Song
2022-05-17  0:15   ` Andrii Nakryiko
2022-05-14  3:12 ` [PATCH bpf-next v2 06/18] libbpf: Add enum64 deduplication support Yonghong Song
2022-05-17  0:28   ` Andrii Nakryiko
2022-05-17 17:11     ` Yonghong Song
2022-05-17 22:22       ` Andrii Nakryiko
2022-05-14  3:12 ` [PATCH bpf-next v2 07/18] libbpf: Add enum64 support for btf_dump Yonghong Song
2022-05-17  0:37   ` Andrii Nakryiko
2022-05-17 17:15     ` Yonghong Song
2022-05-14  3:13 ` [PATCH bpf-next v2 08/18] libbpf: Add enum64 sanitization Yonghong Song
2022-05-17 23:25   ` Andrii Nakryiko
2022-05-18 21:08     ` Yonghong Song
2022-05-14  3:13 ` [PATCH bpf-next v2 09/18] libbpf: Add enum64 support for bpf linking Yonghong Song
2022-05-17 23:25   ` Andrii Nakryiko
2022-05-14  3:13 ` [PATCH bpf-next v2 10/18] libbpf: Add enum64 relocation support Yonghong Song
2022-05-17 23:32   ` Andrii Nakryiko
2022-05-18 21:09     ` Yonghong Song [this message]
2022-05-14  3:13 ` [PATCH bpf-next v2 11/18] bpftool: Add btf enum64 support Yonghong Song
2022-05-17 23:38   ` Andrii Nakryiko
2022-05-18 21:10     ` Yonghong Song
2022-05-14  3:13 ` [PATCH bpf-next v2 12/18] selftests/bpf: Fix selftests failure Yonghong Song
2022-05-17 23:33   ` Andrii Nakryiko
2022-05-14  3:13 ` [PATCH bpf-next v2 13/18] selftests/bpf: Test new enum kflag and enum64 API functions Yonghong Song
2022-05-17 23:40   ` Andrii Nakryiko
2022-05-18 21:12     ` Yonghong Song
2022-05-14  3:13 ` [PATCH bpf-next v2 14/18] selftests/bpf: Add BTF_KIND_ENUM64 unit tests Yonghong Song
2022-05-17 23:41   ` Andrii Nakryiko
2022-05-14  3:13 ` [PATCH bpf-next v2 15/18] selftests/bpf: Test BTF_KIND_ENUM64 for deduplication Yonghong Song
2022-05-17 23:43   ` Andrii Nakryiko
2022-05-14  3:13 ` [PATCH bpf-next v2 16/18] selftests/bpf: Add a test for enum64 value relocations Yonghong Song
2022-05-17 23:45   ` Andrii Nakryiko
2022-05-14  3:13 ` [PATCH bpf-next v2 17/18] selftests/bpf: Clarify llvm dependency with possible selftest failures Yonghong Song
2022-05-17 23:45   ` Andrii Nakryiko
2022-05-14  3:13 ` [PATCH bpf-next v2 18/18] docs/bpf: Update documentation for BTF_KIND_ENUM64 support Yonghong Song
2022-05-17 23:47   ` Andrii Nakryiko
2022-05-18 21:21     ` Yonghong Song

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a5976134-3e16-94ea-fd7b-1053b83747a4@fb.com \
    --to=yhs@fb.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=kernel-team@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox