On Tue, Mar 24, 2020 at 1:54 PM Jordan Niethe <jniet...@gmail.com> wrote: > > On Mon, Mar 23, 2020 at 9:21 PM Nicholas Piggin <npig...@gmail.com> wrote: > > > > Jordan Niethe's on March 23, 2020 7:25 pm: > > > On Mon, Mar 23, 2020 at 5:22 PM Nicholas Piggin <npig...@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
