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
> GCC patch tested by bootstrapping on mips-sgi-irix6.5. Also
> tested mips-elf and mips64-elf (in the latter case, both with
> and without the GAS changes).
(Did you run the assembler/linker checks, as well was check-gcc? I'd
assume so, but just checking. 8-)
> ! 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...
> ! -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?
> ! Note that the @samp{_MIPS_ARCH} uses processor names given above. In
macro?
> ! other words, it will have the full prefix, and will not abbreviate
^ kill this comma. 8-)
> ! @samp{000} as @samp{k}. In the case of @samp{from-abi}, the macro
> ! names the resolved architecture (either @samp{"mips1"} or
> ! @samp{"mips3"}). It names the default architecture when no
> ! @option{-march} option is given.
> !
> ! @item -mtune=@var{arch}
> @opindex mtune
> ! Optimize for @var{arch}. Among other things, this option controls
> ! the way instructions are scheduled, and the perceived cost of arithmetic
> ! operations. The list of @var{arch} values is the same as for
> ! @option{-march}.
>
> ! When this option is not used, GCC will optimize for the processor
> ! specified by @option{-march}, or (failing that) for the default
> ! processor. By using @option{-march} and @option{-mtune} together, it is
"failing that"? Why not just 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} ?
> *** 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-)
chris