[PATCH 2/3] opcodes: discriminate endianness and insn-endianness in CGEN ports

[Jose E. Marchesi]

Hi Alan.
Thanks for the review.

    On Fri, May 29, 2020 at 07:08:19PM +0200, Jose E. Marchesi via Binutils wrote:
    > @@ -906,13 +907,15 @@ gas_cgen_md_apply_fix (fixS *fixP, valueT *valP, segT seg ATTRIBUTE_UNUSED)
    >  	  {
    >  	    CGEN_INSN_INT insn_value =
    >  	      cgen_get_insn_value (cd, (unsigned char *) where,
    > -				   CGEN_INSN_BITSIZE (insn));
    > +				   CGEN_INSN_BITSIZE (insn),
    > +                                   cd->endian);
    >  
    >  	    /* ??? 0 is passed for `pc'.  */
    >  	    errmsg = CGEN_CPU_INSERT_OPERAND (cd) (cd, opindex, fields,
    >  						   &insn_value, (bfd_vma) 0);
    >  	    cgen_put_insn_value (cd, (unsigned char *) where,
    > -				 CGEN_INSN_BITSIZE (insn), insn_value);
    > +				 CGEN_INSN_BITSIZE (insn), insn_value,
    > +                                 cd->endian);
    >  	  }
    >  #else
    >  	  /* ??? 0 is passed for `pc'.  */
    
    The above looks to be a typo.  Shouldn't you be using instruction
    endianness here when modifying instruction operand fields?  The same
    question applies for tc-bpf.c and tc-mep changes.

Hm, that's actually the main point of the patch: for the CGEN-based
ports to being able to use a different endianness for constant opcode
fields than the one used to encode the contents of operand fields.