This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [mips patch RFA] some objdump -M options, better reg dumps


cgd@broadcom.com writes:
> wanted the ability to disable symbolic names for GPRs,

Bless you. ;)

> * MIPS VR4111, MIPS VR4120, MIPS VR5400, and MIPS VR5500 tests are
>   failing for ECOFF now, since objdump opts for those test didn't
>   include the arch specs.  (generally better for MIPS bits to test
>   disassembly w/ explicit arch flags, and test object file markings on
>   a per object file format basis with a separate test.  I'll fix these
>   at some point.)

FWIW, the patch I sent here (unreviewed, nudge, nudge ;)

  http://sources.redhat.com/ml/binutils/2002-12/msg00280.html

could easily have some extra "good_combination" lines so that
it tests all the supported members of the VR series.  If that
patch goes in, I'll add explicit architecture names to the
gas testsuite (should qualify as "obvious").

> +struct mips_arch_choice mips_arch_choices[] = {
> +  { "numeric",	0, 0, 0, 0,
> +    mips_cp0_names_numeric },
> +  { "r3000",	1, bfd_mach_mips3000, CPU_R3000, ISA_MIPS1,
> +    NULL },
> +  { "r3900",	1, bfd_mach_mips3900, CPU_R3900, ISA_MIPS1,
> +    NULL },
> +  { "r4000",	1, bfd_mach_mips4000, CPU_R4000, ISA_MIPS3,
> +    NULL },
> +  { "r4010",	1, bfd_mach_mips4010, CPU_R4010, ISA_MIPS2,
> +    NULL },
> +  { "vr4100",	1, bfd_mach_mips4100, CPU_VR4100, ISA_MIPS3,
> +    NULL },
> +  { "vr4111",	1, bfd_mach_mips4111, CPU_R4111, ISA_MIPS3,
> +    NULL },
> +  { "vr4120",	1, bfd_mach_mips4120, CPU_VR4120, ISA_MIPS3,
> +    NULL },
> +  { "r4300",	1, bfd_mach_mips4300, CPU_R4300, ISA_MIPS3,
> +    NULL },
> +  { "r4400",	1, bfd_mach_mips4400, CPU_R4400, ISA_MIPS3,
> +    NULL },
> +  { "r4600",	1, bfd_mach_mips4600, CPU_R4600, ISA_MIPS3,
> +    NULL },
> +  { "r4650",	1, bfd_mach_mips4650, CPU_R4650, ISA_MIPS3,
> +    NULL },
> +  { "r5000",	1, bfd_mach_mips5000, CPU_R5000, ISA_MIPS4,
> +    NULL },
> +  { "vr5400",	1, bfd_mach_mips5400, CPU_VR5400, ISA_MIPS4,
> +    NULL },
> +  { "vr5500",	1, bfd_mach_mips5500, CPU_VR5500, ISA_MIPS4,
> +    NULL },
> +  { "r6000",	1, bfd_mach_mips6000, CPU_R6000, ISA_MIPS2,
> +    NULL },
> +  { "r8000",	1, bfd_mach_mips8000, CPU_R8000, ISA_MIPS4,
> +    NULL },
> +  { "r10000",	1, bfd_mach_mips10000, CPU_R10000, ISA_MIPS4,
> +    NULL },
> +  { "r12000",	1, bfd_mach_mips12000, CPU_R12000, ISA_MIPS4,
> +    NULL },
> +  { "mips5",	1, bfd_mach_mips5, CPU_MIPS5, ISA_MIPS5,
> +    NULL },
> +  /* For stock MIPS32, disassemble all applicable MIPS-specified ASEs.
> +     Note that MIPS-3D and MDMX are not applicable to MIPS32.  (See
> +     _MIPS32 Architecture For Programmers Volume I: Introduction to the
> +     MIPS32 Architecture_ (MIPS Document Number MD00082, Revision 0.95),
> +     page 1.  */
> +  { "mips32",	1, bfd_mach_mipsisa32, CPU_MIPS32,
> +    ISA_MIPS32 | INSN_MIPS16,
> +    mips_cp0_names_mips3264 },
> +  /* For stock MIPS64, disassemble all applicable MIPS-specified ASEs.  */
> +  { "mips64",	1, bfd_mach_mipsisa64, CPU_MIPS64,
> +    ISA_MIPS64 | INSN_MIPS16 | INSN_MIPS3D | INSN_MDMX,
> +    mips_cp0_names_mips3264 },
> +  { "sb1",	1, bfd_mach_mips_sb1, CPU_SB1,
> +    ISA_MIPS64 | INSN_MIPS3D | INSN_SB1,
> +    mips_cp0_names_sb1 },
> +
> +  /* This entry, mips16, is here only for ISA/processor selection; do
> +     not print its name.  */
> +  { "",		1, bfd_mach_mips16, CPU_MIPS16, ISA_MIPS3 | INSN_MIPS16,
> +    NULL },
> +
> +  { NULL, 0, 0, 0, 0, NULL }
> +};

This looks suspiciously like a subset of the info in tc-mips.c.

Can't we use the same table for both gas and opcodes?  Not only
would it mean less duplicated info, it would mean consistency.
E.g. with the patch it stands, it looks like "4000" isn't accepted
as a synonym for "r4000" by opcodes but it is by gas.

Richard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]