Re: Handling of mips disassembly by gdb

[Will Cohen <wcohen at redhat dot com>]

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.

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?

-Will



Andrew Cagney wrote:
> 
> Will Cohen wrote:
> >
> > The disassembly performed by the function _print_insn_mips in
> > opcode/mips-dis.c is dependent on the mach field of the struct info
> > passed to the function.  Unfortunately the mach field is alway set to
> > zero because TM_PRINT_INSN_MACH is defined to be 0 in
> > gdb/config/mips/tm-mip.h.  Is there a reason that this must be set to
> > zero?  Wouldn't it be more appropriate to set it to
> > ((TARGET_PRINT_INSN_INFO)->mach)? Changing this line allows the
> > disassembler to generate model specific instructions.
> >
> > Should I generate a patch to fix this and submit it to binutils?  Or is
> > there a reason this define was set to zero?
> 
> You may want to check exactly how objdump handles things like MIPS16 vs
> MIPS-1-IV code and ARM vs THUMB.  By default, GDB just calls the
> dissassembler and hopes that it knows what the architecture is for the
> current memory range.
> 
> For your case, does a simple objdump dissassemble code the way you
> expect?
> 
>         Andrew