RFC: Requiring GAS for mips-sgi-irix*

[Richard Sandiford <rsandifo at redhat dot com>]

I'd like get some comments on whether we still need to support the
MIPSpro assembler and linker for IRIX.

Up till now, there hasn't been much alternative but to use MIPSpro.
Both GNU as and ld had several known problems, and indeed, the
installation notes specifically warned against using gas.

Hopefully binutils 2.15 should change all that.  I think it's the first
release for some time to have been extensively tested on IRIX.  And it
does seem to produce good test results.  See, for example, the 3.4 results
posted here: <http://gcc.gnu.org/ml/gcc-testresults/2004-04/msg01277.html>,
which are better than I get with MIPSpro.  In fact, in my testing, the
binutils results have been consistently better than the MIPSpro results
for several months.

Supporting MIPSpro assemblers also has a significant maintanence
overhead, as outlined below.

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?

FWIW, I've made IRIX6.5 binary distributions of binutils & gcc available
at <http://people.redhat.com/~rsandifo/>.


Problems with o32
-----------------

The MIPSpro o32 assembler is very restricted, and supporting it has much
more overhead than the n32 & n64 assembler(s).  Specifically, the MIPSpro
o32 code:

  - Doesn't support any form of debugging info.  Not only is this bad from
    a usability POV, it makes it much harder to get clean test results.

  - Uses sjlj exceptions.

  - Can't use named sections, since the MIPSpro assembler doesn't
    understand them.

It's the only case in which any of these is true for MIPS.  Furthermore:

  - The assembler mishandles labels at the end of the data section.
    This causes link failures for most g77 programs.

  - The assembler doesn't, and never will, support explicit relocation
    operators.

  - The native o32 support has led to bugs like PR14207, in which a
    perfectly innocent change to libstdc++-v3 had to reverted because
    it tickled a MIPSpro bug.

GAS has none of these problems.  In particular, the gas configuration
supports dwarf2 exception handling and dwarf2 debugging info.  You can
use all the usual named section extensions.


Problems with n32 & n64
-----------------------

The n32 & n64 assemblers aren't as bad, but there are still several problems:

  - Some versions are known to mishandle jumps to labels that are
    mentioned in dwarf info.  This has led to several bootstrap
    failures in the past (after innocent changes to large functions
    like fold()).

  - Other assembler bugs keep cropping up.  See for example the second
    paragraph of <http://gcc.gnu.org/ml/gcc-patches/2003-10/msg00404.html>.
    and PR14650.

    (Of course, binutils probably has bugs too, but at least we can
    fix those.  The usual argument in favour of free software...)

  - 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.

  - 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...

Richard