Hi!
On Thu, Oct 06, 2022 at 06:07:32PM +0000, Christophe Leroy wrote:
> Le 23/09/2022 à 08:23, Nicholas Piggin a écrit :
> > I would rather complete prefixed support in the kernel and use pcrel
> > addressing. Actually even if we don't compile with pcrel or prefixed,
> > there are some instructions and we will probably get more that require
> > prefixed, possible we might want to use them in kernel. Some of it is
> > required to handle user mode instructions too. So I think removing
> > it is premature, but I guess it's up for debate.
>
> Well ok, in fact I only had code_patching in mind.
>
> Code patching is only for kernel text. Today code patching is used for
> things like kprobe, ftrace, etc .... which really do not seems to be
> prepared for prefixed instructions.
>
> If you are adding -mno-prefixed, it is worth keeping that code which
> sometimes gives us some headacke ?
-mpcrel requires -mprefixed. Using PC relative addressing will be a
significant performance benefit.
> Of course if there are plans to get real prefixed instruction in kernel
> code anytime soon, lets live with it, in that case the support should
> get completed. But otherwise I think it would be better to get rid of it
> for now, and implement it completely when we need it in years.
The future is unstoppable, certainly the near future is :-)
> When I see the following, I'm having hard time believing it would work
> with prefixed instructions in the kernel text:
>
> typedef u32 kprobe_opcode_t;
>
> struct kprobe {
> ...
> /* Saved opcode (which has been replaced with breakpoint) */
> kprobe_opcode_t opcode;
>
>
> void arch_disarm_kprobe(struct kprobe *p)
> {
> WARN_ON_ONCE(patch_instruction(p->addr, ppc_inst(p->opcode)));
> }
Why would it not work?
Segher
