public inbox for bpf@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii@kernel.org>
To: <bpf@vger.kernel.org>, <ast@kernel.org>, <daniel@iogearbox.net>
Cc: andrii@kernel.org, kernel-team@fb.com,
	"Eduard Zingerman" <eddyz87@gmail.com>,
	"Per Sundström XP" <per.xp.sundstrom@ericsson.com>
Subject: [PATCH bpf-next 2/6] libbpf: handle non-standardly sized enums better in BTF-to-C dumper
Date: Thu, 8 Dec 2022 10:56:59 -0800	[thread overview]
Message-ID: <20221208185703.2681797-3-andrii@kernel.org> (raw)
In-Reply-To: <20221208185703.2681797-1-andrii@kernel.org>

Turns out C allows to force enum to be 1-byte or 8-byte explicitly using
mode(byte) or mode(word), respecticely. Linux sources are using this in
some cases. This is imporant to handle correctly, as enum size
determines corresponding fields in a struct that use that enum type. And
if enum size is incorrect, this will lead to invalid struct layout. So
add mode(byte) and mode(word) attribute support to btf_dump APIs.

Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
---
 tools/lib/bpf/btf_dump.c | 38 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 38 insertions(+)

diff --git a/tools/lib/bpf/btf_dump.c b/tools/lib/bpf/btf_dump.c
index 69e80ee5f70e..234e82334d56 100644
--- a/tools/lib/bpf/btf_dump.c
+++ b/tools/lib/bpf/btf_dump.c
@@ -13,6 +13,7 @@
 #include <ctype.h>
 #include <endian.h>
 #include <errno.h>
+#include <limits.h>
 #include <linux/err.h>
 #include <linux/btf.h>
 #include <linux/kernel.h>
@@ -1076,6 +1077,43 @@ static void btf_dump_emit_enum_def(struct btf_dump *d, __u32 id,
 	else
 		btf_dump_emit_enum64_val(d, t, lvl, vlen);
 	btf_dump_printf(d, "\n%s}", pfx(lvl));
+
+	/* special case enums with special sizes */
+	if (t->size == 1) {
+		/* one-byte enums can be forced with mode(byte) attribute */
+		btf_dump_printf(d, " __attribute__((mode(byte)))");
+	} else if (t->size == 8 && d->ptr_sz == 8) {
+		/* enum can be 8-byte sized if one of the enumerator values
+		 * doesn't fit in 32-bit integer, or by adding mode(word)
+		 * attribute (but probably only on 64-bit architectures); do
+		 * our best here to try to satisfy the contract without adding
+		 * unnecessary attributes
+		 */
+		bool needs_word_mode;
+
+		if (btf_is_enum(t)) {
+			/* enum can't represent 64-bit values, so we need word mode */
+			needs_word_mode = true;
+		} else {
+			/* enum64 needs mode(word) if none of its values has
+			 * non-zero upper 32-bits (which means that all values
+			 * fit in 32-bit integers and won't cause compiler to
+			 * bump enum to be 64-bit naturally
+			 */
+			int i;
+
+			needs_word_mode = true;
+			for (i = 0; i < vlen; i++) {
+				if (btf_enum64(t)[i].val_hi32 != 0) {
+					needs_word_mode = false;
+					break;
+				}
+			}
+		}
+		if (needs_word_mode)
+			btf_dump_printf(d, " __attribute__((mode(word)))");
+	}
+
 }
 
 static void btf_dump_emit_fwd_def(struct btf_dump *d, __u32 id,
-- 
2.30.2


  parent reply	other threads:[~2022-12-08 18:57 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 ` Andrii Nakryiko [this message]
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
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=20221208185703.2681797-3-andrii@kernel.org \
    --to=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --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