Handling of mips disassembly by gdb

[Andrew Cagney]

Will Cohen wrote:
> 
> objdump worked the way I expected.  It would disassemble the file using
> the instructions in the architecture specified in the file.
> 
> Before I changed TM_PRINT_INSN_MACH gdb would not correctly disassemble
> instructions for the mips variants.  I traced the problem to
> TM_PRINT_INSN_MACH.  Once I replaced "0" with
> "((TARGET_PRINT_INSN_INFO)->mach)" disassembly for mips variants worked
> much better gdb when disassembling instructions that are not in the base
> mips instruction set.

I don't know that it works for a MIPS16/MIPS executable. Can you examine
an executable that includes MIPS16 instructions to see what the value of
->mach is?

> My question was "what was there a reason for TM_PRINT_INSN_MACH set to
> 0," e.g. gdb has different mechanism to handle instruction set variants
> and TM_PRINT_INSN_MACH is just an artifact that is going away?

Unfortunatly GDB doesn't have a standard mechanism for handling
different ISAs in a single object file.  It uses a combiation of gaffer
tape, glue (sniff) and opcodes.  Solving the problem is somewhere on the
list of things to do when finishing multi-arch.

Hmm, I don't think your patch will work if the user alternates between
mips16 then mipsXXX code.  Looking at mips-tdep.c:gdb_print_insn_mips()
it would:

	o	blat info->mach with bfd_mach_mips16

	o	blat info->mach with ((TARGET_PRINT_INSN_INFO)->mach)
		unfortunatly, that is equivalent to info->mach = info->mach

Can I suggest:

	o	creating a local copy of the info argumet
		and blatting that.

	o	adding an assertion that, when the address
		is even, ->mach is never bfd_mach_mips16.

	o	eliminating TM_PRINT_INSN_MACH from
		that mips file.

	Andrew