RE: I've broken my binutils version 2.28

["Maciej W. Rozycki" <macro at imgtec dot com>]

On Fri, 15 Sep 2017, ANDY KENNEDY wrote:

> A specific question:  In the file include/opcode/mips.h, I see lines
> like:
> 
> #define INSN_OCTEON3              0x00000040
> #define INSN_XLR                  0x00000020
> 
> 
> In the patch I stole from the web years ago, I found this:
> 
> #define INSN_XLP                  0x00000040
> 
> 0x00000040 is now Octeon3's spot.  What values are acceptable for this
> match?

 Any unused bits except those claimed by INSN_ISA_MASK are free to take.  
Make sure you have updated INSN_CHIP_MASK accordingly.

>  I see where it XLR and OCTEON3 are used below in
> cpu_is_member(), but I also see there are no more unique values.  I
> attempted to try 0x00000080 as a value, but that seems to be defined as:
> 
> #define ASE_MT                  0x00000080
> 
> which I would expect would collide with that target.

 Nope, INSN_* and ASE_* macros are used in different places these days.  

> Am I allowed to use something like:
> 
> #define INSN_XLP                  0xdeadbee40
> 
> to make it unique enough?

 No, the data structure the chip INSN_* macros are used with is a bit 
field, because a vendor-specific instruction can be implemented in more 
than just one processor type.

 Overall when adding support for a new CPU I advise looking through GIT 
history for an earlier addition, to see what's needed to get it done 
properly.  See e.g. commit 2c62985659da ("MIPS: Add Octeon 3 support") for 
a fairly straightforward recent update.

  Maciej