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: Will Cohen <wcohen at redhat dot com>
- Subject: Re: Handling of mips disassembly by gdb
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Sat, 20 Jan 2001 10:44:08 +1100
- Cc: gdb at sourceware dot cygnus dot com
- References: <39F0C5E9.CC6A0CF9@redhat.com> <3A67009D.4AEBD43B@cygnus.com> <3A686DA1.15830F3E@redhat.com>
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