Re: [RFC PATCH 2/3] LoongArch: Add larch_insn_gen_break() to generate break insn

[WANG Xuerui]

On 2023/4/7 20:02, Tiezhu Yang wrote:
> On 04/07/2023 05:51 PM, WANG Xuerui wrote:
> > On 2023/4/7 10:30, Youling Tang wrote:
> > > /* snip */
> > >
> > > > diff --git a/arch/loongarch/kernel/kprobes.c
> > > > b/arch/loongarch/kernel/kprobes.c
> > > > index 08c78d2..a5c3712 100644
> > > > --- a/arch/loongarch/kernel/kprobes.c
> > > > +++ b/arch/loongarch/kernel/kprobes.c
> > > > @@ -4,19 +4,8 @@
> > > >  #include <linux/preempt.h>
> > > >  #include <asm/break.h>
> > > >
> > > > -static const union loongarch_instruction breakpoint_insn = {
> > > > -    .reg0i15_format = {
> > > > -        .opcode = break_op,
> > > > -        .immediate = BRK_KPROBE_BP,
> > > > -    }
> > > > -};
> > > > -
> > > > -static const union loongarch_instruction singlestep_insn = {
> > > > -    .reg0i15_format = {
> > > > -        .opcode = break_op,
> > > > -        .immediate = BRK_KPROBE_SSTEPBP,
> > > > -    }
> > > > -};
> > > > +#define breakpoint_insn larch_insn_gen_break(BRK_KPROBE_BP)
> > > > +#define singlestep_insn larch_insn_gen_break(BRK_KPROBE_SSTEPBP)
> > >
> > > IMO, Defined as KPROBE_BP_INSN, KPROBE_SSTEPBP_INSN may be better.
> >
> > Are you suggesting to hardcode the instruction words for those two BREAK
> > flavors?
>
> I think what Youling said is:
>
> #define KPROBE_BP_INSN         larch_insn_gen_break(BRK_KPROBE_BP)
> #define KPROBE_SSTEPBP_INSN    larch_insn_gen_break(BRK_KPROBE_SSTEPBP)
>
> > I don't think it's better because even more structured info is
> > lost, and the compiler would generate the same code (if not, it's the
> > compiler that's to be fixed).
> >
> > Actually, I don't know why this commit was necessary in the first place.
> > For the very least, it consisted of two logical changes (pass around
> > instruction words instead of unions; and change the BREAK insns to make
> > them words) that should get split;
>
> Yes, thanks for your suggestion, I will split it into two patches
> in the next version.
>
> > but again, the generated code should
> > be identical anyway, so it seems a lot of churn for no benefit and
> > reduced readability.
>
> Define and use larch_insn_gen_break() is to avoid hardcoding the
> uprobe break instruction in patch #3.
>
> We do not like the following definitions:
>
> #define UPROBE_SWBP_INSN    0x002a000c
> #define UPROBE_XOLBP_INSN    0x002a000d
>
> Using larch_insn_gen_break() seems better:
>
> #define UPROBE_SWBP_INSN    larch_insn_gen_break(BRK_UPROBE_BP)
> #define UPROBE_XOLBP_INSN    larch_insn_gen_break(BRK_UPROBE_XOLBP)

Sorry, I meant *not* ditching the union-typed parameters. IMO they 
should behave the same codegen-wise (i.e. unchanged performance), and 
have the benefit of being clearly typed unlike plain u32's.

--
WANG "xen0n" Xuerui

Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/