This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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: RFC: Requiring GAS for mips-sgi-irix*


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)


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