From: Pu Lehui <pulehui@huawei.com> To: Andrii Nakryiko <andrii.nakryiko@gmail.com> Cc: bpf <bpf@vger.kernel.org>, open list <linux-kernel@vger.kernel.org>, Networking <netdev@vger.kernel.org>, <linux-riscv@lists.infradead.org>, Andrii Nakryiko <andrii@kernel.org>, Alexei Starovoitov <ast@kernel.org>, Daniel Borkmann <daniel@iogearbox.net>, Martin Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>, Yonghong Song <yhs@fb.com>, john fastabend <john.fastabend@gmail.com>, KP Singh <kpsingh@kernel.org>, Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu> Subject: Re: [PATCH bpf-next] libbpf: Support riscv USDT argument parsing logic Date: Tue, 19 Apr 2022 21:00:15 +0800 [thread overview] Message-ID: <ef4ffe1f-1f3b-e98e-fc5f-26150e22871f@huawei.com> (raw) In-Reply-To: <CAEf4BzbavSC=JN=sowFY3t4yOUfe8QtVXhdG+y7a-T1YtfRqXQ@mail.gmail.com> On 2022/4/19 12:33, Andrii Nakryiko wrote: > On Sun, Apr 17, 2022 at 8:53 PM Pu Lehui <pulehui@huawei.com> wrote: >> >> Add riscv-specific USDT argument specification parsing logic. >> riscv USDT argument format is shown below: >> - Memory dereference case: >> "size@off(reg)", e.g. "-8@-88(s0)" >> - Constant value case: >> "size@val", e.g. "4@5" >> - Register read case: >> "size@reg", e.g. "-8@a1" >> >> s8 will be marked as poison while it's a reg of riscv, we need >> to alias it in advance. >> >> Signed-off-by: Pu Lehui <pulehui@huawei.com> >> --- > > Can you please mention briefly the testing you performed as I'm not > able to test this locally. > Both RV32 and RV64 have been tested. I will attach the test result in v2. Meanwhile, I found a small problem with libbpf USDT, and will be post in v2. >> tools/lib/bpf/usdt.c | 107 +++++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 107 insertions(+) >> >> diff --git a/tools/lib/bpf/usdt.c b/tools/lib/bpf/usdt.c >> index 934c25301ac1..b8af409cc763 100644 >> --- a/tools/lib/bpf/usdt.c >> +++ b/tools/lib/bpf/usdt.c >> @@ -10,6 +10,11 @@ >> #include <linux/ptrace.h> >> #include <linux/kernel.h> >> >> +/* s8 will be marked as poison while it's a reg of riscv */ >> +#if defined(__riscv) >> +#define rv_s8 s8 >> +#endif >> + >> #include "bpf.h" >> #include "libbpf.h" >> #include "libbpf_common.h" >> @@ -1400,6 +1405,108 @@ static int parse_usdt_arg(const char *arg_str, int arg_num, struct usdt_arg_spec >> return len; >> } >> >> +#elif defined(__riscv) >> + >> +static int calc_pt_regs_off(const char *reg_name) >> +{ >> + static struct { >> + const char *name; >> + size_t pt_regs_off; >> + } reg_map[] = { >> + { "ra", offsetof(struct user_regs_struct, ra) }, >> + { "sp", offsetof(struct user_regs_struct, sp) }, >> + { "gp", offsetof(struct user_regs_struct, gp) }, >> + { "tp", offsetof(struct user_regs_struct, tp) }, >> + { "t0", offsetof(struct user_regs_struct, t0) }, >> + { "t1", offsetof(struct user_regs_struct, t1) }, >> + { "t2", offsetof(struct user_regs_struct, t2) }, >> + { "s0", offsetof(struct user_regs_struct, s0) }, >> + { "s1", offsetof(struct user_regs_struct, s1) }, >> + { "a0", offsetof(struct user_regs_struct, a0) }, >> + { "a1", offsetof(struct user_regs_struct, a1) }, >> + { "a2", offsetof(struct user_regs_struct, a2) }, >> + { "a3", offsetof(struct user_regs_struct, a3) }, >> + { "a4", offsetof(struct user_regs_struct, a4) }, >> + { "a5", offsetof(struct user_regs_struct, a5) }, >> + { "a6", offsetof(struct user_regs_struct, a6) }, >> + { "a7", offsetof(struct user_regs_struct, a7) }, >> + { "s2", offsetof(struct user_regs_struct, s2) }, >> + { "s3", offsetof(struct user_regs_struct, s3) }, >> + { "s4", offsetof(struct user_regs_struct, s4) }, >> + { "s5", offsetof(struct user_regs_struct, s5) }, >> + { "s6", offsetof(struct user_regs_struct, s6) }, >> + { "s7", offsetof(struct user_regs_struct, s7) }, >> + { "s8", offsetof(struct user_regs_struct, rv_s8) }, >> + { "s9", offsetof(struct user_regs_struct, s9) }, >> + { "s10", offsetof(struct user_regs_struct, s10) }, >> + { "s11", offsetof(struct user_regs_struct, s11) }, >> + { "t3", offsetof(struct user_regs_struct, t3) }, >> + { "t4", offsetof(struct user_regs_struct, t4) }, >> + { "t5", offsetof(struct user_regs_struct, t5) }, >> + { "t6", offsetof(struct user_regs_struct, t6) }, > > would it make sense to order registers a bit more "logically"? Like > s0-s11, t0-t6, etc. Right now it looks very random and it's hard to > see if all the registers from some range of registers are defined. > I code it according to the RISCV specification, and for sure, we can make it more intuitive. Thanks, Lehui >> + }; >> + int i; >> + > > [...] > . >
WARNING: multiple messages have this Message-ID (diff)
From: Pu Lehui <pulehui@huawei.com> To: Andrii Nakryiko <andrii.nakryiko@gmail.com> Cc: bpf <bpf@vger.kernel.org>, open list <linux-kernel@vger.kernel.org>, Networking <netdev@vger.kernel.org>, <linux-riscv@lists.infradead.org>, Andrii Nakryiko <andrii@kernel.org>, Alexei Starovoitov <ast@kernel.org>, Daniel Borkmann <daniel@iogearbox.net>, Martin Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>, Yonghong Song <yhs@fb.com>, john fastabend <john.fastabend@gmail.com>, KP Singh <kpsingh@kernel.org>, Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu> Subject: Re: [PATCH bpf-next] libbpf: Support riscv USDT argument parsing logic Date: Tue, 19 Apr 2022 21:00:15 +0800 [thread overview] Message-ID: <ef4ffe1f-1f3b-e98e-fc5f-26150e22871f@huawei.com> (raw) In-Reply-To: <CAEf4BzbavSC=JN=sowFY3t4yOUfe8QtVXhdG+y7a-T1YtfRqXQ@mail.gmail.com> On 2022/4/19 12:33, Andrii Nakryiko wrote: > On Sun, Apr 17, 2022 at 8:53 PM Pu Lehui <pulehui@huawei.com> wrote: >> >> Add riscv-specific USDT argument specification parsing logic. >> riscv USDT argument format is shown below: >> - Memory dereference case: >> "size@off(reg)", e.g. "-8@-88(s0)" >> - Constant value case: >> "size@val", e.g. "4@5" >> - Register read case: >> "size@reg", e.g. "-8@a1" >> >> s8 will be marked as poison while it's a reg of riscv, we need >> to alias it in advance. >> >> Signed-off-by: Pu Lehui <pulehui@huawei.com> >> --- > > Can you please mention briefly the testing you performed as I'm not > able to test this locally. > Both RV32 and RV64 have been tested. I will attach the test result in v2. Meanwhile, I found a small problem with libbpf USDT, and will be post in v2. >> tools/lib/bpf/usdt.c | 107 +++++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 107 insertions(+) >> >> diff --git a/tools/lib/bpf/usdt.c b/tools/lib/bpf/usdt.c >> index 934c25301ac1..b8af409cc763 100644 >> --- a/tools/lib/bpf/usdt.c >> +++ b/tools/lib/bpf/usdt.c >> @@ -10,6 +10,11 @@ >> #include <linux/ptrace.h> >> #include <linux/kernel.h> >> >> +/* s8 will be marked as poison while it's a reg of riscv */ >> +#if defined(__riscv) >> +#define rv_s8 s8 >> +#endif >> + >> #include "bpf.h" >> #include "libbpf.h" >> #include "libbpf_common.h" >> @@ -1400,6 +1405,108 @@ static int parse_usdt_arg(const char *arg_str, int arg_num, struct usdt_arg_spec >> return len; >> } >> >> +#elif defined(__riscv) >> + >> +static int calc_pt_regs_off(const char *reg_name) >> +{ >> + static struct { >> + const char *name; >> + size_t pt_regs_off; >> + } reg_map[] = { >> + { "ra", offsetof(struct user_regs_struct, ra) }, >> + { "sp", offsetof(struct user_regs_struct, sp) }, >> + { "gp", offsetof(struct user_regs_struct, gp) }, >> + { "tp", offsetof(struct user_regs_struct, tp) }, >> + { "t0", offsetof(struct user_regs_struct, t0) }, >> + { "t1", offsetof(struct user_regs_struct, t1) }, >> + { "t2", offsetof(struct user_regs_struct, t2) }, >> + { "s0", offsetof(struct user_regs_struct, s0) }, >> + { "s1", offsetof(struct user_regs_struct, s1) }, >> + { "a0", offsetof(struct user_regs_struct, a0) }, >> + { "a1", offsetof(struct user_regs_struct, a1) }, >> + { "a2", offsetof(struct user_regs_struct, a2) }, >> + { "a3", offsetof(struct user_regs_struct, a3) }, >> + { "a4", offsetof(struct user_regs_struct, a4) }, >> + { "a5", offsetof(struct user_regs_struct, a5) }, >> + { "a6", offsetof(struct user_regs_struct, a6) }, >> + { "a7", offsetof(struct user_regs_struct, a7) }, >> + { "s2", offsetof(struct user_regs_struct, s2) }, >> + { "s3", offsetof(struct user_regs_struct, s3) }, >> + { "s4", offsetof(struct user_regs_struct, s4) }, >> + { "s5", offsetof(struct user_regs_struct, s5) }, >> + { "s6", offsetof(struct user_regs_struct, s6) }, >> + { "s7", offsetof(struct user_regs_struct, s7) }, >> + { "s8", offsetof(struct user_regs_struct, rv_s8) }, >> + { "s9", offsetof(struct user_regs_struct, s9) }, >> + { "s10", offsetof(struct user_regs_struct, s10) }, >> + { "s11", offsetof(struct user_regs_struct, s11) }, >> + { "t3", offsetof(struct user_regs_struct, t3) }, >> + { "t4", offsetof(struct user_regs_struct, t4) }, >> + { "t5", offsetof(struct user_regs_struct, t5) }, >> + { "t6", offsetof(struct user_regs_struct, t6) }, > > would it make sense to order registers a bit more "logically"? Like > s0-s11, t0-t6, etc. Right now it looks very random and it's hard to > see if all the registers from some range of registers are defined. > I code it according to the RISCV specification, and for sure, we can make it more intuitive. Thanks, Lehui >> + }; >> + int i; >> + > > [...] > . > _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2022-04-19 13:00 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-18 4:22 [PATCH bpf-next] libbpf: Support riscv USDT argument parsing logic Pu Lehui 2022-04-18 4:22 ` Pu Lehui 2022-04-19 4:33 ` Andrii Nakryiko 2022-04-19 4:33 ` Andrii Nakryiko 2022-04-19 13:00 ` Pu Lehui [this message] 2022-04-19 13:00 ` Pu Lehui
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=ef4ffe1f-1f3b-e98e-fc5f-26150e22871f@huawei.com \ --to=pulehui@huawei.com \ --cc=andrii.nakryiko@gmail.com \ --cc=andrii@kernel.org \ --cc=aou@eecs.berkeley.edu \ --cc=ast@kernel.org \ --cc=bpf@vger.kernel.org \ --cc=daniel@iogearbox.net \ --cc=john.fastabend@gmail.com \ --cc=kafai@fb.com \ --cc=kpsingh@kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-riscv@lists.infradead.org \ --cc=netdev@vger.kernel.org \ --cc=palmer@dabbelt.com \ --cc=paul.walmsley@sifive.com \ --cc=songliubraving@fb.com \ --cc=yhs@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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.