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

[Jose E. Marchesi]

        >  	  {
        >  	    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.

Argh please scratch that, you are right.  It was a typo, in both
gas/cgen.c and gas/config/gc-mep.c.  It didn't break anything due to the
fact endian == insn_endian in all the impacted targets, but an error
nevertheless.  Fixing it.

On the other hand this doesn't apply to the BPF port: the
cgen_put_insn_value in gas/config/tc-bpf.c should definitely use endian
and not insn_endian.