This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: Requiring GAS for mips-sgi-irix*
- From: Albert Chin-A-Young <gcc at mlists dot thewrittenword 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 09:25:54 -0500
- Subject: Re: RFC: Requiring GAS for mips-sgi-irix*
- References: <87isdg7y2q.fsf@redhat.com>
- Reply-to: gcc at gcc dot gnu dot org
On Fri, Jun 25, 2004 at 11:04:45AM +0100, Richard Sandiford wrote:
> I'd like get some comments on whether we still need to support the
> MIPSpro assembler and linker for IRIX.
> ...
> I think there are several alternatives:
>
> (1) what we have now: support both the MIPSpro assembler & MIPSpro linker
> (2) require GAS for o32, otherwise continue with what we have now
> (3) require GAS for all ABIs, but continue to support the MIPSpro linker
> (4) require binutils across the board
>
> I'm not ready to promote (4) yet since the overhead of supporting the
> linker is much smaller than the overhead of supporting the assembler.
> I'm not saying it's a bad idea either, mind. ;)
>
> I would like to suggest to (3) though. Any comments?
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. HP-UX already requires binutils as
for correct debugging info.
We routinely build with MIPSpro on IRIX and use GCC only where needed
so compatibility between cc object file is important. o32 doesn't
matter to us at all.
> Problems with n32 & n64
> -----------------------
>
> The n32 & n64 assemblers aren't as bad, but there are still several problems:
>
> - 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
binutils?
> - 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.
--
albert chin (china@thewrittenword.com)