This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: unexpected NOP encodings
On Tue, Jun 25, 2019 at 09:29:51AM -0500, Peter Bergner wrote:
> On 6/24/19 10:36 PM, Alan Modra wrote:
> > + /* Any selection of opcodes based on ppc_cpu after gas has finished
> > + parsing the file is invalid. md_apply_fix and ppc_handle_align
> > + must select opcodes based on the machine in force at the point
> > + where the fixup or alignment frag was created, not the machine in
> > + force at the end of file. */
> > + ppc_cpu = 0;
>
> I think the use of ppc_cpu in md_assemble() is problematical as well.
> If we chose an opcode due to -many rather than a -m<cpu>/.machine value,
> then the current ppc_cpu value in effect may have nothing to do with the
> current insn, and yet we use ppc_cpu when calling ppc_optional_operand_value
> (not used at the moment, but could be in the future) as well as when inserting
> operands and the dialect is used for some operands. I think we should be
> using opcode->flags rather than ppc_cpu in md_assemble(). Do you agree?
There may well be some insert/extract functions that should be taking
note of PPC_OPCODE_ANY in "dialect", but I don't see any real problem
in using ppc_cpu. Yes, you could drive everything from the opcode
flags, but that would require duplicate opcode table entries and
insert/extract functions.
--
Alan Modra
Australia Development Lab, IBM