This is the mail archive of the
mailing list for the GDB project.
Re: Handling of mips disassembly by gdb
- To: Will Cohen <wcohen at redhat dot com>
- Subject: Re: Handling of mips disassembly by gdb
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Fri, 19 Jan 2001 01:41:33 +1100
- Cc: gdb at sourceware dot cygnus dot com
- References: <39F0C5E9.CC6A0CF9@redhat.com>
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