Re: binutils snapshots no longer build gas

Re: binutils snapshots no longer build gas

[Ken Raeburn]

   Date: Sun, 23 Apr 1995 04:10:10 -0400
   From: "David Edelsohn" <dje@watson.ibm.com>

	   gas has been added to the list of noconfigdirs in configure.in
   for all rs6000 and powerpc architectures.  Has gas support really
   regressed?  And "cvs" is inconsistent between the various entries: I believe
   that it is supported for all AIX configurations.

I think the problem was that gas couldn't handle certain types of
debugging information used in XCOFF format.  Maybe having to do with
inline functions from header files?  Ian knows the details, but he's
on leave.

I don't know why cvs is disabled for powerpc-*-aix* when it's enabled
for rs6000-*-aix*.  But I'll leave that for the cvs maintainers to
deal with.

	   Also, because binutils is not supported, c++filt is not
   built although it does not rely upon the rest of binutils functionality.
   Mike Stump was suppose to address this but it still is broken.

I think Jason has been working on making c++filt independent of
binutils in some form.

Re: binutils snapshots no longer build gas

[David Edelsohn]

>>>>> Ken Raeburn writes:

Ken> I think the problem was that gas couldn't handle certain types of
Ken> debugging information used in XCOFF format.  Maybe having to do with
Ken> inline functions from header files?  Ian knows the details, but he's on
Ken> leave.

	GAS does have some limitations with respect to XCOFF support
including the problem with included files which you mention, but I do not
understand why that is important enough to disable the AIX XCOFF
configuration of GAS.  Some support is better than no support: IBM XAS still
is distributed with AIX 4.1 so one can use that if one encounters the
debugging information limitation.

David
===============================================================================
David Edelsohn                                      T.J. Watson Research Center
dje@watson.ibm.com                                  P.O. Box 218
+1 808 879 5077                                     Yorktown Heights, NY 10598

Re: binutils snapshots no longer build gas

[Ken Raeburn]

	   GAS does have some limitations with respect to XCOFF support
   including the problem with included files which you mention, but I do not
   understand why that is important enough to disable the AIX XCOFF
   configuration of GAS.  Some support is better than no support: IBM XAS still
   is distributed with AIX 4.1 so one can use that if one encounters the
   debugging information limitation.

I think it's a question of which works better, and what the default
should be for naive users.  If the native assembler is going to work
significantly better, we can't really justify shipping to customers
paying for the end result a toolchain using the inferior GNU one
instead.  If no native assembler exists (e.g., for embedded targets)
then using the GNU one makes sense.

You can of course override the top-level configure.in script and use
gas on such machines if you really want to.  Even better, you can do
that, and then send in patches to make gas and bfd work really well on
XCOFF. :-)

But does building and installing gas by default really gain the
average user anything that makes up for the problems in debugging?
Apparently Jim Kingdon -- one of the gdb maintainers -- didn't think
so.

Ken

Re: binutils snapshots no longer build gas

[David Edelsohn]

	The current state implies that GAS does not build or function at all.
I agree that making GAS the default system assembler may cause some
problems for users, but not building GAS at all seems to be an incorrect
solution at the opposite extreme.  At IBM Watson, I have gas from
binutils-2.5.2 installed as "gas" not "as".  I think the biggest problem
with the current distribution is that this debugging problem is hidden in
a FIXME comment instead of in the GAS documentation for the AIX XCOFF
configuration.  I would let the user/installer decide whether s/he wants
a partially functional GAS instead of implying that no functionality exists.
	Also, AIX XAS has a bug not present in GAS which prevents it from
assembling certain GCC output for the POWER/2 architecture.  XAS incorrectly
exits with an error when it see certain POWER/2 and POWER instructions
utilized in the same assembler source file believing that it is an invalid
combination.

David

Re: binutils snapshots no longer build gas

[Ken Raeburn]

	   The current state implies that GAS does not build or function at all.

It should only imply that we don't currently recommend using it.

   I agree that making GAS the default system assembler may cause some
   problems for users, but not building GAS at all seems to be an incorrect
   solution at the opposite extreme.  At IBM Watson, I have gas from
   binutils-2.5.2 installed as "gas" not "as".  I think the biggest problem
   with the current distribution is that this debugging problem is hidden in
   a FIXME comment instead of in the GAS documentation for the AIX XCOFF
   configuration.  I would let the user/installer decide whether s/he wants
   a partially functional GAS instead of implying that no functionality exists.

Makes sense.  But I still think the default for the relatively
clueless user should be the safer path.  In this case, not using gas.
Perhaps we could change the top-level configure.in to include gas if
"--with-gnu-as" is supplied.

	   Also, AIX XAS has a bug not present in GAS which prevents it from
   assembling certain GCC output for the POWER/2 architecture.  XAS incorrectly
   exits with an error when it see certain POWER/2 and POWER instructions
   utilized in the same assembler source file believing that it is an invalid
   combination.

Hm..  This changes things.  The user's going to lose either way.
Perhaps it's worth re-evaluating whether the gas bug can be fixed.
Mike Meissner is doing powerpc gas work at Cygnus right now; I've
asked him to take a look.

Is there a fixed assembler available from IBM?  It would be worth
mentioning in the gcc documentation whether or not gas would work.
And it would make having gas available less critical.