This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Handling of mips disassembly by gdb
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: Handling of mips disassembly by gdb
- From: Will Cohen <wcohen at redhat dot com>
- Date: Fri, 19 Jan 2001 11:38:57 -0500
- CC: gdb at sourceware dot cygnus dot com
- Organization: Red Hat, Inc.
- References: <39F0C5E9.CC6A0CF9@redhat.com> <3A67009D.4AEBD43B@cygnus.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