From: Andrii Nakryiko <andrii.nakryiko@gmail.com> To: Pu Lehui <pulehui@huawei.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: Mon, 18 Apr 2022 21:33:26 -0700 [thread overview] Message-ID: <CAEf4BzbavSC=JN=sowFY3t4yOUfe8QtVXhdG+y7a-T1YtfRqXQ@mail.gmail.com> (raw) In-Reply-To: <20220418042222.2464199-1-pulehui@huawei.com> 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. > 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. > + }; > + int i; > + [...]
WARNING: multiple messages have this Message-ID (diff)
From: Andrii Nakryiko <andrii.nakryiko@gmail.com> To: Pu Lehui <pulehui@huawei.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: Mon, 18 Apr 2022 21:33:26 -0700 [thread overview] Message-ID: <CAEf4BzbavSC=JN=sowFY3t4yOUfe8QtVXhdG+y7a-T1YtfRqXQ@mail.gmail.com> (raw) In-Reply-To: <20220418042222.2464199-1-pulehui@huawei.com> 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. > 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. > + }; > + 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 4:33 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 [this message] 2022-04-19 4:33 ` Andrii Nakryiko 2022-04-19 13:00 ` Pu Lehui 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='CAEf4BzbavSC=JN=sowFY3t4yOUfe8QtVXhdG+y7a-T1YtfRqXQ@mail.gmail.com' \ --to=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=pulehui@huawei.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.