This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]