This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [Revised patch] Rework MIPS command-line handling
Thanks for the comments.
cgd@broadcom.com writes:
> > ! first = 1;
> >
> > for (i = 0; mips_cpu_info_table[i].name != NULL; i++)
> > ! show (stream, mips_cpu_info_table[i].name, &column, &first);
> > ! show (stream, "from-abi", &column, &first);
>
> So, given that there's some duplication of name -> CPU mappings in the
> cpu names table (4600 vs. orion, some of the SB-1 related names hich
> i plan to clean up after you commit this), does it make sense to print
> out only the first name for a given CPU (since presumably that's the
> preferred name)?
>
> It might be nice to have an additional field 'deprecated' to allow old
> names to persist a bit, with warnings (and w/o being printed)... but
> that can be added later...
If you like. I don't see any particular reason not to print both
orion & 4600: it makes it clear both names are recognised. I'll
leave the sb1 decision to you ;). But FWIW, yes, I'd much prefer
a "deprecated" flag over a long list of show() calls. Maybe
convert is_isa to a bitmask of flags?
> > ! -mabi=ABI create ABI conformant object file for:\n"));
> > !
> > ! first = 1;
> > !
> > ! show (stream, "32", &column, &first);
> > ! show (stream, "o64", &column, &first);
> > ! show (stream, "n32", &column, &first);
> > ! show (stream, "64", &column, &first);
> > ! show (stream, "eabi", &column, &first);
> > !
> > ! fputc ('\n', stream);
>
> missing meabi?
Well, gas doesn't recognise meabi. I haven't added it as part of this
patch because there isn't anything we can do with it yet.
BTW, GCC just doesn't pass an ABI flag in this case. I guess
changes.html should read: "ELF configurations will always pass an ABI
flag to the assembler, except when the MIPS EABI is selected.".
> > ! Note that the @samp{_MIPS_ARCH} uses processor names given above. In
>
> macro?
Will fix.
> > ! other words, it will have the full prefix, and will not abbreviate
>
> ^ kill this comma. 8-)
Hmm, OK.
> "failing that"? Why not just kill ", or ..."?
I'll kill ", or ...".
> > ! The default size of ints, longs and pointers depends on the ABI@.
> > ! All the supported ABIs use 32-bit ints. n64 uses 64-bit longs, as does
>
> @samp{n64} ?
Wanted to name the ABI rather than the -mabi argument.
How about "SGI's n64 ABI"?
> > *** config/mips/iris6.h 11 Jul 2002 18:56:56 -0000 1.50
> > --- config/mips/iris6.h 19 Jul 2002 18:37:50 -0000
> > *************** Boston, MA 02111-1307, USA. */
> > *** 238,244 ****
> > on the mipsX option. */
> > /* If no mips[3,4] option given, give the appropriate default for mabi=X */
> > #undef SUBTARGET_ASM_SPEC
> > ! #define SUBTARGET_ASM_SPEC "%{!mabi*:-n32} %{!mips*: %{!mabi*:-mips3} %{mabi=n32:-mips3} %{mabi=64:-mips4}}"
> >
> > /* Must pass -g0 to the assembler, otherwise it may overwrite our
> > debug info with its own debug info. */
> > --- 238,244 ----
> > on the mipsX option. */
> > /* If no mips[3,4] option given, give the appropriate default for mabi=X */
> > #undef SUBTARGET_ASM_SPEC
> > ! #define SUBTARGET_ASM_SPEC "%{!mabi*:-n32} %{!mips*: %{!mabi*:-mips3} %{mabi=n32|mabi=64:-mips3}}"
> >
>
> Is this change to the existing / historical behaviour desirable? Or
> is it just a necessary side effect of the rest of the changes (i.e.,
> consistency)? Eh, i guess i don't really care. 8-)
Well, it's partly a necessary side effect. It used to be
override_options that switched to -mips4. So I had to either add a
-mabi=64 -> -mips4 rule to SUBTARGET_CC1_SPEC, or make the change above.
And PR 5938 (filed by SGI, no less) says that -mabi=64 should generate
MIPS III code by default, so that it can run on R4400 systems.
Richard