From: Alan Maguire <alan.maguire@oracle.com>
To: Quentin Monnet <qmo@kernel.org>,
Eduard Zingerman <eddyz87@gmail.com>,
ast@kernel.org, andrii@kernel.org, jolsa@kernel.org
Cc: daniel@iogearbox.net, ihor.solodrai@linux.dev,
yonghong.song@linux.dev, song@kernel.org, martin.lau@linux.dev,
memxor@gmail.com, emil@etsalapatis.com, bpf@vger.kernel.org,
nsc@kernel.org, puranjay@kernel.org, yatsenko@meta.com
Subject: Re: [PATCH v3 bpf-next 09/11] bpftool: Add ability to dump LOC_PARAM, LOC_PROTO and LOCSEC
Date: Wed, 23 Sep 2026 09:47:09 +0100 [thread overview]
Message-ID: <3c1247d4-3ef8-427a-8514-51d2cd9aa136@oracle.com> (raw)
In-Reply-To: <5af8a42e-ce2f-443c-bdad-2e989dcc1a9b@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 4564 bytes --]
On 22/09/2026 12:59, Quentin Monnet wrote:
> 2026-09-21 14:46 UTC-0700 ~ Eduard Zingerman <eddyz87@gmail.com>
>> On Mon, 2026-09-21 at 19:47 +0100, Alan Maguire wrote:
>>> On 18/09/2026 21:51, Eduard Zingerman wrote:
>>>> On Wed, 2026-09-16 at 08:41 +0100, Alan Maguire wrote:
>>>>
>>>> ...
>>>>
>>>>> +static void btf_loc_param_str(const struct btf_type *t, char *str, size_t sz)
>>>>> +{
>>>>> + const struct btf_loc_param *p;
>>>>> + __u32 i = 0, vlen;
>>>>> + __u64 value;
>>>>> + bool negative = false;
>>>>> + char regs[32] = {};
>>>>> + char num[32] = {};
>>>>> + const char *op = "";
>>>>> +
>>>>> + if (!t || !btf_is_loc_param(t)) {
>>>>> + snprintf(str, sz, "<invalid>");
>>>>> + return;
>>>>> + }
>>>>> +
>>>>> + p = btf_loc_param(t);
>>>>> + vlen = btf_vlen(t);
>>>>> +
>>>>> + if (p->flags & BTF_LOC_PARAM_REG) {
>>>>> + __u32 nregs = (p->flags == BTF_LOC_PARAM_REG) ? vlen : 1;
>>>>> +
>>>>> + if (nregs > vlen) {
>>>>> + snprintf(str, sz, "?");
>>>>> + return;
>>>>> + }
>>>>> +
>>>>> + switch (nregs) {
>>>>> + case 2:
>>>>> + snprintf(regs, sizeof(regs), "r%u, r%u",
>>>>> + p->values[0], p->values[1]);
>>>>
>>>> I agree with Jiri regarding the register names. It's not a huge table,
>>>> e.g. [1], 20 lines for x86 ~> 100-200 lines that would not really
>>>> change to handle all architectures that have BPF jits.
>>>> And it would be very convenient for those using the tool.
>>>>
>>>
>>> Yeah, it's doable, it's just that it is more portable when done in
>>> pfunct; we can use dwfl interface to get register names [1]. With
>>> pfunct changes in that tree we get output that is either arch-independent
>>> (standalone BTF) or when combined with ELF info from vmlinux
>>> gives us the arch-specific register names, containing function etc.
>>> To see the inline site for ip_send_skb for example:
>>>
>>> $ pfunct --inline_sites -f ip_send_skb --elf vmlinux /sys/kernel/btf/vmlinux.inline
>>> 0xffffffff8201f241 [ip_push_pending_frames+0x31, .text +0x101f241] ip_send_skb(struct net * net [%rbx], struct sk_buff * skb [%rax])
>>>
>>> (above does not need DWARF at all, just BTF + ELF info, so will work with a
>>> debuginfo-stripped vmlinux)
>>>
>>> So for me the tool to reach for in understanding the raw BTF is
>>> bpftool, whereas to apply the arch-specific transformations, locate the
>>> absolute addresses etc I'd use pfunct. But that's just me; I'm happy to
>>> go with the consensus here. Given the current library support, I think
>>> maintaining per-arch tables in bpftool (rather than introducing a new
>>> library dependency) would be the way to go if we do add it.
>>>
>>> Quentin, what do you think? Are per-arch tables for registers in bpftool
>>> ok from your side? Thanks!
>>>
>>> Alan
>>>
>>> [1] https://github.com/alan-maguire/dwarves/blob/0da899665b04f16c3f68c0b736834a15e045c3c9/pfunct.c#L95
>>
>> Adding dwfl as an (optional?) dependency for bpftool and reusing the
>> same code as [1] might be an option as well.
>>
>> ...
>
>
> If we decide to go with arch-specific transformation, I think I'd rather
> go with local tables rather than adding a dependency, unless it turns
> out to be necessary. But Alan's argument makes sense to me, bpftool
> prints the literal BTF encoding, and resolving to per-arch instructions
> is probably best left to pfunct.
>
Thanks Quentin! To investigate I implemented the table for i386, x86_64,
aarch64 and s390 (attached). So while it is technically straightforward
what I realized however is that we have to make an architecture
choice that isn't available from /sys/kernel/btf data directly. So we
are stuck using the arch bpftool has been compiled to (unless we add
another parameter to pass to bpftool raw dump). So while "use the same
arch as bpftool" is likely often the right answer, we might sometimes
want to examine raw BTF for another architecture. That feels to me like
an argument for more neutral raw output too.
I've updated pfunct a bit to handle a few situations
- raw BTF only; no reg interpretation, no absolute address resolution
- raw BTF + --elf file option ; adds per-arch reg interpretation, containing function and
absolute address resolution
- raw BTF + --running option ; uses reg interpretation, kallsyms/module data
to do address and containing function resolution that is kASLR-friendly
So the logical split is bpftool tells me what the BTF is; pfunct tells
me what it means in the context of the associated ELF file or running kernel.
Anyway we can go either way, but FWIW my vote is to keep bpftool
arch-neutral. Thanks!
Alan
[-- Attachment #2: 0009-bpftool-Add-ability-to-dump-LOC_PARAM-LOC_PROTO-and-.patch --]
[-- Type: text/x-patch, Size: 9569 bytes --]
From 2929a894efff4e60be5c712345e36dc16bdd2b7e Mon Sep 17 00:00:00 2001
From: Alan Maguire <alan.maguire@oracle.com>
Date: Thu, 18 Sep 2025 09:19:04 +0000
Subject: [PATCH v4 bpf-next 09/11] bpftool: Add ability to dump LOC_PARAM,
LOC_PROTO and LOCSEC
In raw mode ensure we can dump new BTF kinds in normal/json format.
BTF_KIND_LOC_PARAMs are rendered as strings, for example a
const value of 0x2a and a dereference of %r10 + 0x20:
[12] LOC_PARAM '(anon)' size=4 flags=0x2 vlen=1 values='0x2a'
[13] LOC_PARAM '(anon)' size=8 flags=0x38 vlen=2 values='*(%r10 + 0x20)'
LOC_PROTOs render the associated values of each of their
LOC_PARAMs for easier readability:
[14] LOC_PROTO '(anon)' vlen=2
type_id=12 value='0x2a'
type_id=13 value='*(%r10 + 0x20)'
and LOCSEC shows function name associated with site:
[15] LOCSEC 'inline.text' vlen=1
name='foo' func_type_id=5 loc_proto_type_id=14 offset=64
Registers are displayed as their arch-specific DW_OP_reg*
equivalents where available.
Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
---
tools/bpf/bpftool/btf.c | 264 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 264 insertions(+)
diff --git a/tools/bpf/bpftool/btf.c b/tools/bpf/bpftool/btf.c
index 65e8a29277e6..384fef2dadff 100644
--- a/tools/bpf/bpftool/btf.c
+++ b/tools/bpf/bpftool/btf.c
@@ -29,6 +29,40 @@
#define MAX_ROOT_IDS 16
#define MAX_BTF_FILES 64
+#define MAX_LOC_PARAM_WORDS 8
+
+/* DWARF register numbers used by BTF_KIND_LOC_PARAM. */
+#if defined(__x86_64__)
+static const char * const btf_dwarf_reg_names[] = {
+ "rax", "rdx", "rcx", "rbx", "rsi", "rdi", "rbp", "rsp",
+ "r8", "r9", "r10", "r11", "r12", "r13", "r14", "r15", "rip",
+};
+#elif defined(__i386__)
+static const char * const btf_dwarf_reg_names[] = {
+ "eax", "ecx", "edx", "ebx", "esp", "ebp", "esi", "edi", "eip",
+};
+#elif defined(__aarch64__)
+static const char * const btf_dwarf_reg_names[] = {
+ "x0", "x1", "x2", "x3", "x4", "x5", "x6", "x7",
+ "x8", "x9", "x10", "x11", "x12", "x13", "x14", "x15",
+ "x16", "x17", "x18", "x19", "x20", "x21", "x22", "x23",
+ "x24", "x25", "x26", "x27", "x28", "x29", "lr", "sp",
+};
+#elif defined(__s390x__) || defined(__s390__)
+static const char * const btf_dwarf_reg_names[] = {
+ "r0", "r1", "r2", "r3", "r4", "r5", "r6", "r7",
+ "r8", "r9", "r10", "r11", "r12", "r13", "r14", "r15",
+ "f0", "f2", "f4", "f6", "f1", "f3", "f5", "f7",
+ "f8", "f10", "f12", "f14", "f9", "f11", "f13", "f15",
+ "c0", "c1", "c2", "c3", "c4", "c5", "c6", "c7",
+ "c8", "c9", "c10", "c11", "c12", "c13", "c14", "c15",
+ "a0", "a1", "a2", "a3", "a4", "a5", "a6", "a7",
+ "a8", "a9", "a10", "a11", "a12", "a13", "a14", "a15",
+ "pswm", "pswa",
+};
+#else
+static const char * const btf_dwarf_reg_names[] = {};
+#endif
static const char * const btf_kind_str[NR_BTF_KINDS] = {
[BTF_KIND_UNKN] = "UNKNOWN",
@@ -51,6 +85,9 @@ static const char * const btf_kind_str[NR_BTF_KINDS] = {
[BTF_KIND_DECL_TAG] = "DECL_TAG",
[BTF_KIND_TYPE_TAG] = "TYPE_TAG",
[BTF_KIND_ENUM64] = "ENUM64",
+ [BTF_KIND_LOC_PARAM] = "LOC_PARAM",
+ [BTF_KIND_LOC_PROTO] = "LOC_PROTO",
+ [BTF_KIND_LOCSEC] = "LOCSEC",
};
struct sort_datum {
@@ -117,6 +154,144 @@ static int btf_kind_safe(int kind)
return kind <= BTF_KIND_MAX ? kind : BTF_KIND_UNKN;
}
+static void btf_loc_param_reg_str(__u32 reg, char *str, size_t sz)
+{
+ const char *name = NULL;
+
+ if (reg < ARRAY_SIZE(btf_dwarf_reg_names))
+ name = btf_dwarf_reg_names[reg];
+ if (name)
+ snprintf(str, sz, "%%%s", name);
+ else
+ snprintf(str, sz, "r%u", reg);
+}
+
+static void btf_loc_param_raw_str(const struct btf_loc_param *p, __u32 vlen,
+ char *str, size_t sz)
+{
+ __u32 i, nr_words = min(vlen, (__u32)MAX_LOC_PARAM_WORDS);
+ size_t off = 0;
+
+ if (!sz)
+ return;
+
+ off += snprintf(str + off, sz - off, "raw=[");
+ for (i = 0; i < nr_words && off < sz; i++)
+ off += snprintf(str + off, sz - off, "%s0x%08x",
+ i ? ", " : "", p->values[i]);
+ if (vlen > nr_words && off < sz)
+ off += snprintf(str + off, sz - off, ", ...");
+ if (off < sz)
+ snprintf(str + off, sz - off, "]");
+}
+
+static void btf_loc_param_str(const struct btf_type *t, char *str, size_t sz)
+{
+ const struct btf_loc_param *p;
+ __u32 i = 0, vlen;
+ __u64 value;
+ __u32 value_size;
+ bool negative = false;
+ char regs[32] = {};
+ char num[32] = {};
+ const char *op = "";
+
+ if (!t || !btf_is_loc_param(t)) {
+ snprintf(str, sz, "<invalid>");
+ return;
+ }
+
+ p = btf_loc_param(t);
+ vlen = btf_vlen(t);
+
+ if (p->flags & BTF_LOC_PARAM_REG) {
+ __u32 nregs = (p->flags == BTF_LOC_PARAM_REG) ? vlen : 1;
+
+ if (nregs > vlen) {
+ btf_loc_param_raw_str(p, vlen, str, sz);
+ return;
+ }
+
+ switch (nregs) {
+ case 2:
+ btf_loc_param_reg_str(p->values[0], regs, sizeof(regs));
+ snprintf(regs + strlen(regs), sizeof(regs) - strlen(regs),
+ ", ");
+ btf_loc_param_reg_str(p->values[1],
+ regs + strlen(regs),
+ sizeof(regs) - strlen(regs));
+ break;
+ case 1:
+ if (p->values[0] == BTF_LOC_PARAM_FBREG)
+ snprintf(regs, sizeof(regs), "fbreg");
+ else
+ btf_loc_param_reg_str(p->values[0], regs, sizeof(regs));
+ break;
+ default:
+ btf_loc_param_raw_str(p, vlen, str, sz);
+ return;
+ }
+ i += nregs;
+ }
+ if (p->flags & (BTF_LOC_PARAM_CONST|BTF_LOC_PARAM_OFFSET)) {
+ switch (vlen - i) {
+ case 1:
+ value_size = sizeof(p->values[0]);
+ value = p->values[i];
+ break;
+ case 2:
+ value_size = 2 * sizeof(p->values[0]);
+ value = ((__u64)p->values[i + 1] << 32) | p->values[i];
+ break;
+ default:
+ btf_loc_param_raw_str(p, vlen, str, sz);
+ return;
+ }
+ i = vlen;
+ if (p->flags & BTF_LOC_PARAM_SIGNED) {
+ /*
+ * size describes the represented parameter, so it
+ * describes a constant's signed width. An offset
+ * is determined by its value words after the register
+ * number.
+ */
+ __u32 size = p->flags & BTF_LOC_PARAM_OFFSET ?
+ value_size : t->size;
+ __u32 bits = size * 8;
+
+ /*
+ * Since we represent constant values in hex, we
+ * need to determine if the value is negative so
+ * we can prepend a "-", and also fix the value
+ * to be positive so we can have - 0x<value>.
+ */
+ if (size && size <= sizeof(value)) {
+ if (size < sizeof(value))
+ value &= (1ULL << bits) - 1;
+ negative = value & (1ULL << (bits - 1));
+ if (negative)
+ value = size == sizeof(value) ? -value :
+ (1ULL << bits) - value;
+ }
+ }
+ snprintf(num, sizeof(num), "0x%llx%s", (unsigned long long)value,
+ p->flags & BTF_LOC_PARAM_ADDR ? " (addr)" : "");
+ }
+ if (i != vlen) {
+ btf_loc_param_raw_str(p, vlen, str, sz);
+ return;
+ }
+ if (num[0])
+ op = regs[0] ? (negative ? " - " : " + ") : negative ? "-" : "";
+
+ snprintf(str, sz, "%s%s%s%s%s",
+ p->flags & BTF_LOC_PARAM_DEREF ? "*(" : "",
+ regs,
+ op,
+ num,
+ p->flags & BTF_LOC_PARAM_DEREF ? ")" : "");
+}
+
static int dump_btf_type(const struct btf *btf, __u32 id,
const struct btf_type *t)
{
@@ -415,6 +590,95 @@ static int dump_btf_type(const struct btf *btf, __u32 id,
}
break;
}
+ case BTF_KIND_LOC_PARAM: {
+ const struct btf_loc_param *p = btf_loc_param(t);
+ __u32 vlen = btf_vlen(t);
+ char param_str[256] = {};
+
+ btf_loc_param_str(t, param_str, sizeof(param_str));
+
+ if (json_output) {
+ jsonw_uint_field(w, "size", t->size);
+ jsonw_uint_field(w, "flags", p->flags);
+ jsonw_uint_field(w, "vlen", vlen);
+ jsonw_string_field(w, "values", param_str);
+ } else {
+ printf(" size=%u flags=0x%x vlen=%u values='%s'",
+ t->size, p->flags, vlen, param_str);
+ }
+ break;
+ }
+ case BTF_KIND_LOC_PROTO: {
+ __u32 *params = btf_loc_proto_params(t);
+ __u32 i, vlen = btf_vlen(t);
+
+ if (json_output) {
+ jsonw_uint_field(w, "vlen", vlen);
+ jsonw_name(w, "params");
+ jsonw_start_array(w);
+ } else {
+ printf(" vlen=%u", vlen);
+ }
+
+ for (i = 0; i < vlen; i++, params++) {
+ const struct btf_type *p;
+ char param_str[256] = {};
+
+ if (*params) {
+ p = btf__type_by_id(btf, *params);
+ btf_loc_param_str(p, param_str, sizeof(param_str));
+ } else {
+ snprintf(param_str, sizeof(param_str), "<unavailable>");
+ }
+ if (json_output) {
+ jsonw_start_object(w);
+ jsonw_uint_field(w, "type_id", *params);
+ jsonw_string_field(w, "value", param_str);
+ jsonw_end_object(w);
+ } else {
+ printf("\n\ttype_id=%u value='%s'", *params, param_str);
+ }
+ }
+ if (json_output)
+ jsonw_end_array(w);
+ break;
+ }
+
+ case BTF_KIND_LOCSEC: {
+ struct btf_loc *locs = btf_locsec_locs(t);
+ __u32 i, vlen = btf_vlen(t);
+
+ if (json_output) {
+ jsonw_uint_field(w, "vlen", vlen);
+ jsonw_name(w, "locs");
+ jsonw_start_array(w);
+ } else {
+ printf(" vlen=%u", vlen);
+ }
+
+ for (i = 0; i < vlen; i++, locs++) {
+ const struct btf_type *f = btf__type_by_id(btf, locs->func);
+ const char *name = "<invalid>";
+
+ if (f && btf_is_func(f))
+ name = btf_str(btf, f->name_off);
+
+ if (json_output) {
+ jsonw_start_object(w);
+ jsonw_uint_field(w, "func_type_id", locs->func);
+ jsonw_string_field(w, "name", name);
+ jsonw_uint_field(w, "loc_proto_type_id", locs->loc_proto);
+ jsonw_uint_field(w, "offset", locs->offset);
+ jsonw_end_object(w);
+ } else {
+ printf("\n\tname='%s' func_type_id=%u loc_proto_type_id=%u offset=%u",
+ name, locs->func, locs->loc_proto, locs->offset);
+ }
+ }
+ if (json_output)
+ jsonw_end_array(w);
+ break;
+ }
default:
break;
}
--
2.43.5
next prev parent reply other threads:[~2026-09-23 8:47 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-16 7:41 [PATCH v3 bpf-next 00/11] Support inline functions in BTF Alan Maguire
2026-09-16 7:41 ` [PATCH v3 bpf-next 01/11] btf: Extend UAPI to support BTF location (inline site) info Alan Maguire
2026-09-16 9:03 ` bot+bpf-ci
2026-09-16 7:41 ` [PATCH v3 bpf-next 02/11] libbpf: Add support for BTF kinds LOC[_PARAM|_PROTO|SEC] Alan Maguire
2026-09-16 7:55 ` sashiko-bot
2026-09-16 9:03 ` bot+bpf-ci
2026-09-16 7:41 ` [PATCH v3 bpf-next 03/11] selftests/bpf: Test helper support for BTF_KIND_LOC[_PARAM|_PROTO|SEC] Alan Maguire
2026-09-16 8:44 ` bot+bpf-ci
2026-09-18 18:34 ` Eduard Zingerman
2026-09-16 7:41 ` [PATCH v3 bpf-next 04/11] selftests/bpf: Add LOC_PARAM, LOC_PROTO, LOCSEC to field iter tests Alan Maguire
2026-09-18 18:43 ` Eduard Zingerman
2026-09-16 7:41 ` [PATCH v3 bpf-next 05/11] selftests/bpf: Add LOC_PARAM, LOC_PROTO, LOCSEC to dedup split tests Alan Maguire
2026-09-18 18:46 ` Eduard Zingerman
2026-09-16 7:41 ` [PATCH v3 bpf-next 06/11] selftests/bpf: BTF distill tests to ensure LOC[_PARAM|_PROTO] add to split BTF Alan Maguire
2026-09-18 19:59 ` Eduard Zingerman
2026-09-21 18:36 ` Alan Maguire
2026-09-16 7:41 ` [PATCH v3 bpf-next 07/11] bpftool: Handle multi-split BTF by supporting multiple base BTFs Alan Maguire
2026-09-16 7:54 ` sashiko-bot
2026-09-16 9:03 ` bot+bpf-ci
2026-09-16 7:41 ` [PATCH v3 bpf-next 08/11] bpftool: Document support for multi-split BTF Alan Maguire
2026-09-16 7:41 ` [PATCH v3 bpf-next 09/11] bpftool: Add ability to dump LOC_PARAM, LOC_PROTO and LOCSEC Alan Maguire
2026-09-16 7:55 ` sashiko-bot
2026-09-16 9:03 ` bot+bpf-ci
2026-09-16 22:07 ` Jiri Olsa
2026-09-17 8:27 ` Alan Maguire
2026-09-17 22:00 ` Jiri Olsa
2026-09-18 9:19 ` Alan Maguire
2026-09-18 13:01 ` Jiri Olsa
2026-09-17 16:06 ` Quentin Monnet
2026-09-17 17:32 ` Alan Maguire
2026-09-18 7:29 ` Alan Maguire
2026-09-18 20:51 ` Eduard Zingerman
2026-09-21 18:47 ` Alan Maguire
2026-09-21 21:46 ` Eduard Zingerman
2026-09-22 11:59 ` Quentin Monnet
2026-09-23 8:47 ` Alan Maguire [this message]
2026-09-16 7:41 ` [PATCH v3 bpf-next 10/11] selftests/bpf: Test bpftool dump of BTF location info Alan Maguire
2026-09-16 7:56 ` sashiko-bot
2026-09-16 9:03 ` bot+bpf-ci
2026-09-16 7:41 ` [PATCH v3 bpf-next 11/11] Documentation/bpf: Describe new location-related BTF kinds Alan Maguire
2026-09-16 8:01 ` sashiko-bot
2026-09-16 9:03 ` bot+bpf-ci
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=3c1247d4-3ef8-427a-8514-51d2cd9aa136@oracle.com \
--to=alan.maguire@oracle.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=ihor.solodrai@linux.dev \
--cc=jolsa@kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=nsc@kernel.org \
--cc=puranjay@kernel.org \
--cc=qmo@kernel.org \
--cc=song@kernel.org \
--cc=yatsenko@meta.com \
--cc=yonghong.song@linux.dev \
/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