From: Eduard Zingerman <eddyz87@gmail.com>
To: Andrii Nakryiko <andrii@kernel.org>,
bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net
Cc: kernel-team@fb.com, "Per Sundström XP" <per.xp.sundstrom@ericsson.com>
Subject: Re: [PATCH bpf-next 3/6] selftests/bpf: add non-standardly sized enum tests for btf_dump
Date: Fri, 09 Dec 2022 19:32:27 +0200 [thread overview]
Message-ID: <5452514a9cf33315d5c179b8494ddd3e7eac2228.camel@gmail.com> (raw)
In-Reply-To: <20221208185703.2681797-4-andrii@kernel.org>
On Thu, 2022-12-08 at 10:57 -0800, Andrii Nakryiko wrote:
> Add few custom enum definitions testing mode(byte) and mode(word)
> attributes.
>
> Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
> ---
> .../bpf/progs/btf_dump_test_case_syntax.c | 36 +++++++++++++++++++
> 1 file changed, 36 insertions(+)
>
> diff --git a/tools/testing/selftests/bpf/progs/btf_dump_test_case_syntax.c b/tools/testing/selftests/bpf/progs/btf_dump_test_case_syntax.c
> index 4ee4748133fe..26fffb02ed10 100644
> --- a/tools/testing/selftests/bpf/progs/btf_dump_test_case_syntax.c
> +++ b/tools/testing/selftests/bpf/progs/btf_dump_test_case_syntax.c
> @@ -25,6 +25,39 @@ typedef enum {
> H = 2,
> } e3_t;
>
> +/* ----- START-EXPECTED-OUTPUT ----- */
> +/*
> + *enum e_byte {
> + * EBYTE_1 = 0,
> + * EBYTE_2 = 1,
> + *} __attribute__((mode(byte)));
> + *
> + */
> +/* ----- END-EXPECTED-OUTPUT ----- */
> +enum e_byte {
> + EBYTE_1,
> + EBYTE_2,
> +} __attribute__((mode(byte)));
> +
> +/* ----- START-EXPECTED-OUTPUT ----- */
> +/*
> + *enum e_word {
> + * EWORD_1 = 0LL,
> + * EWORD_2 = 1LL,
> + *} __attribute__((mode(word)));
> + *
> + */
> +/* ----- END-EXPECTED-OUTPUT ----- */
> +enum e_word {
> + EWORD_1,
> + EWORD_2,
> +} __attribute__((mode(word))); /* force to use 8-byte backing for this enum */
> +
> +/* ----- START-EXPECTED-OUTPUT ----- */
> +enum e_big {
> + EBIG_1 = 1000000000000ULL,
> +};
> +
> typedef int int_t;
>
Something is off with this test, when executed on my little-endian
machine the output looks as follows:
# ./test_progs -n 23/1
--- - 2022-12-09 17:22:03.412602033 +0000
+++ /tmp/btf_dump_test_case_syntax.output.Z28uhX 2022-12-09 17:22:03.403945082 +0000
@@ -23,13 +23,13 @@
} __attribute__((mode(byte)));
enum e_word {
- EWORD_1 = 0LL,
- EWORD_2 = 1LL,
+ EWORD_1 = 0,
+ EWORD_2 = 1,
} __attribute__((mode(word)));
enum e_big {
- EBIG_1 = 1000000000000ULL,
-};
+ EBIG_1 = 3567587328,
+} __attribute__((mode(word)));
But this is not related to your changes, here is a raw dump:
$ bpftool btf dump file ./btf_dump_test_case_syntax.bpf.o
[10] ENUM 'e_big' encoding=UNSIGNED size=8 vlen=1
'EBIG_1' val=3567587328
> typedef volatile const int * volatile const crazy_ptr_t;
> @@ -224,6 +257,9 @@ struct root_struct {
> enum e2 _2;
> e2_t _2_1;
> e3_t _2_2;
> + enum e_byte _100;
> + enum e_word _101;
> + enum e_big _102;
> struct struct_w_typedefs _3;
> anon_struct_t _7;
> struct struct_fwd *_8;
next prev parent reply other threads:[~2022-12-09 17:32 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-08 18:56 [PATCH bpf-next 0/6] BTF-to-C dumper fixes and improvements Andrii Nakryiko
2022-12-08 18:56 ` [PATCH bpf-next 1/6] libbpf: fix single-line struct definition output in btf_dump Andrii Nakryiko
2022-12-08 18:56 ` [PATCH bpf-next 2/6] libbpf: handle non-standardly sized enums better in BTF-to-C dumper Andrii Nakryiko
2022-12-08 18:57 ` [PATCH bpf-next 3/6] selftests/bpf: add non-standardly sized enum tests for btf_dump Andrii Nakryiko
2022-12-09 17:32 ` Eduard Zingerman [this message]
2022-12-12 18:45 ` Andrii Nakryiko
2022-12-12 18:48 ` Eduard Zingerman
2022-12-08 18:57 ` [PATCH bpf-next 4/6] libbpf: fix btf__align_of() by taking into account field offsets Andrii Nakryiko
2022-12-08 18:57 ` [PATCH bpf-next 5/6] libbpf: fix BTF-to-C converter's padding logic Andrii Nakryiko
2022-12-09 17:21 ` Eduard Zingerman
2022-12-12 18:44 ` Andrii Nakryiko
2022-12-12 18:59 ` Eduard Zingerman
2022-12-08 18:57 ` [PATCH bpf-next 6/6] selftests/bpf: add few corner cases to test padding handling of btf_dump Andrii Nakryiko
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=5452514a9cf33315d5c179b8494ddd3e7eac2228.camel@gmail.com \
--to=eddyz87@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kernel-team@fb.com \
--cc=per.xp.sundstrom@ericsson.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