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: [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


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