[PATCH v4 00/16] Initial Prefixed Instruction support

[Jordan Niethe]

On Tue, Mar 24, 2020 at 1:54 PM Jordan Niethe <jniethe5 at gmail.com> wrote:
>
> On Mon, Mar 23, 2020 at 9:21 PM Nicholas Piggin <npiggin at gmail.com> wrote:
> >
> > Jordan Niethe's on March 23, 2020 7:25 pm:
> > > On Mon, Mar 23, 2020 at 5:22 PM Nicholas Piggin <npiggin at gmail.com> wrote:
> > >>
> > >> Jordan Niethe's on March 20, 2020 3:17 pm:
> > >> > A future revision of the ISA will introduce prefixed instructions. A
> > >> > prefixed instruction is composed of a 4-byte prefix followed by a
> > >> > 4-byte suffix.
> > >> >
> > >> > All prefixes have the major opcode 1. A prefix will never be a valid
> > >> > word instruction. A suffix may be an existing word instruction or a
> > >> > new instruction.
> > >> >
> > >> > This series enables prefixed instructions and extends the instruction
> > >> > emulation to support them. Then the places where prefixed instructions
> > >> > might need to be emulated are updated.
> > >> >
> > >> > The series is based on top of:
> > >> > https://patchwork.ozlabs.org/patch/1232619/ as this will effect
> > >> > kprobes.
> > >> >
> > >> > v4 is based on feedback from Nick Piggins, Christophe Leroy and Daniel Axtens.
> > >> > The major changes:
> > >> >     - Move xmon breakpoints from data section to text section
> > >> >     - Introduce a data type for instructions on powerpc
> > >>
> > >> Thanks for doing this, looks like a lot of work, I hope it works out :)
> > >>
> > > Yes it did end up touching a lot of places. I started thinking that
> > > that maybe it would be simpler to just use a u64 instead of the struct
> > > for  instructions.
> > > If we always keep the word instruction / prefix in the lower bytes,
> > > all of the current masking should still work and we can use operators
> > > again instead of ppc_inst_equal(), etc.
> >
> > Yeah.. I think now that you've done it, I prefer it this way.
> Sorry, just to be clear which way do you mean?
> >
> > > It also makes printing easier. We could just #define INST_FMT %llx or
> > > #define INST_FMT %x on powerpc32 and use that for printing out
> > > instructions.
> >
> > Well, not sure about that. Would it make endian concerns more
> > complicated? Print format for prefix might be '%016llx', but we
> > don't want that for all instructions only prefixed ones, and I
> > don't know if that is the way to go either.
> Hm yeah that is true.
> >
> > We'll want to adopt some convention for displaying prefixed
> > instruction bytes, but I don't know what what works best. I wonder
> > if binutils or any userspace tools have a convention.
> binutils-gdb upstream has supports disassembling prefixed instructions.
> Here is what objdump looks like:
>   44:    00 00 00 60     nop
>   48:    00 00 00 07     pnop
>   4c:    00 00 00 00
>   50:    01 00 20 39     li      r9,1
>   54:    00 00 00 06     paddi   r4,r9,3
>   58:    03 00 89 38
>   5c:    00 00 62 3c     addis   r3,r2,0
And this is what it looks like if you use objdump with -w
  44:    00 00 00 60     nop
  48:    00 00 00 07 00 00 00 00     pnop
  50:    01 00 20 39                 li      r9,1
  54:    00 00 00 06 03 00 89 38     paddi   r4,r9,3
  5c:    00 00 62 3c                 addis   r3,r2,0    5c:
R_PPC64_TOC16_HA    .toc+0x10

> >
> > Which reminds me, you might have missed show_instructions()?
> > Although maybe you don't need that until we start using them in
> > the kernel.
> You are right I missed that here.
> >
> > Thanks,
> > Nick