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

[Richard Sandiford <rsandifo at redhat dot com>]

cgd@broadcom.com writes:
> I didn't read it _really_ carefully, but your patch looks pretty good
> to me.
> 
> My one concern is about the mips_32bit_flags_p fn.  Not sure it'll
> indicate 32-bit in all the appropriate cases, because the ABI markings
> are recent...  Though i guess pre-ABI markings, you'd go by
> EF_MIPS_ARCH anyway.  Seesm reasonable I guess.

Like you say, the idea is to rely on EF_MIPS_ARCH when neither
EF_MIPS_32BITMODE or EF_MIPS_ABI is used (just like we do now).

> Also, for code clarity, personally I'd avoid the array-of-arrays and
> go for an array of struct like:
> 
> 	struct mips_mach_extentions {
> 		unsigned long extension;
> 		unsigned long base;
> 	}
> 
> then make mips_mach_extensions be defined in terms of it.

OK.

> Not sure what type is appropriate; i do know that a fair number of
> places seem to use 'unsigned long' for BFD machine type defines.
> (e.g. the disassembler, i believe.)

OK, unsigned long it is.

> > > +struct mips_arch_choice mips_arch_choices[] = {
> > > [...]
> > This looks suspiciously like a subset of the info in tc-mips.c.

[BTW, what I meant to say was, the names are a subset of the names
in tc-mips.c.]

> Yes, there's a lot of the same information but:
> 
> * some of the entries are different.  In particular, mips32 and mips64
>   disassemble the ASEs, and you _do not_ want to assemble them by
>   default IMO.

The ASE flags could be in a separate field.  They might be useful
in a shared table anyway, since gas could then do a bit more sanity
checking.

> * it has more info than the table in tc-mips.c.  (cp0 reg names, soon
>   hwr names, eventually hopefully cp2 reg names, bfd number.)

I agree that the register name stuff probably only belong in opcodes,
but you could key it off the bfd mach.  I'd still rather see the
common bits (name -> cpu/isa/bfd mach mapping) in a single place.

> * the dis one doesn't have the 'is this an isa' flag.

The flag might be useful in a common table, though.

> > Can't we use the same table for both gas and opcodes?  Not only
> > would it mean less duplicated info, it would mean consistency.
> 
> Well, we can't have that!
> 
> It's slightly worse than that, actually: Right now the table and IIRC
> also the lookup code in gas is also duplicated in gcc (w/ instructions
> to keep them in sync).

Yeah, well, that's an unfortunate side-effect of the way the src
& gcc repositories have to be kept separate.  It would be much easier
to share a table between binutils modules.

> I.e., there's already sharing, and I don't know if that sharing can be
> compatible w/ merging the table for assembly and disassembly.
> 
> These tables are useful in at least:
> 
> * gas (assembly)
> * gcc (arch selection)
> * opcodes (disassembly)
> 
> Now, the question obviously arises, "how do you do that?"  That's
> non-obvious to me especially given the fact that the table really
> would like to include bfd-related constants.

We could drop unwanted info from the table if the entries were
written using macros, much like gcc's rtl.def and tree.def.  E.g.

    ARCH ("vr4120",  3, CPU_4120, bfd_mach_mips4120, ...)
    ARCH ("sb1",    64, CPU_SB1,  bfd_mach_mips_sb1, INSN_MIPS3D | ...)

I'm not sure whether it's easier (logistically) to have
a single file shared between gcc & src or whether it's
easier to keep them separate.  But if we're going to use
a table like this in two parts of binutils, it might be
worth trying the experiment there first.

> b) i'd rather not wait for the perfect solution, to get the basic
> functionality implemented.

OK.  I'll try to do a common table "some time" next year. ;)

Richard