This is the mail archive of the
mailing list for the GCC project.
Re: RFC: Requiring GAS for mips-sgi-irix*
- From: Richard Sandiford <rsandifo at redhat dot com>
- To: gcc at gcc dot gnu dot org
- Cc: david dot billinghurst at comalco dot riotinto dot com dot au, ro at techfak dot uni-bielefeld dot de, ghazi at infinite dot rutgers dot edu, echristo at redhat dot com
- Date: Fri, 25 Jun 2004 19:15:06 +0100
- Subject: Re: RFC: Requiring GAS for mips-sgi-irix*
- References: <email@example.com><20040625142553.GA65117@mail1.thewrittenword.com>
Albert Chin-A-Young <firstname.lastname@example.org> writes:
> I would like to see continued support for MIPSpro as/ld. Support for
> binutils as only isn't a problem as long as the resulting .o files are
> compatible with MIPSpro CC/cc/as.
Yes, gas is supposed to be compatible. --with-gnu-as --without-gnu-ld
has been tested and seemed to work.
>> - Different versions support different things. E.g. some versions don't
>> support .gpword <http://gcc.gnu.org/ml/gcc-patches/2002-12/msg00818.html>
>> while others do. Some support the full set of explicit relocation
>> operators, others don't.
> And you won't run into a similar problem with a future version of
Yes, if new features are added to gcc later, and they rely on
gas features. But we'll know precisely which versions of gas
support it and which don't, and we'll be able to advise users
accordingly. It's tended to be trial & error with MIPSpro.
>> - The .section statement doesn't work the way GCC expects: the alignment
>> specified by the first ".section .foo" statement applies to all subsequent
>> ".section .foo" statements. We get around this by:
>> - redirecting asm output to a temporary file
>> - remembering the highest alignment for each section
>> - emitting appropriate section statements at the top of asm_out_file
>> - copying the contents of the temporary file after it
>> It would sure be nice to see this hack go away...
> Is the maintenance burden high for this? Seems that if it's done once,
> you don't need to worry about it anymore.
You'd think ;) But I know that I've had to patch this code myself,
so the burden certainly isn't zero.