Re: Misleading error message from gas/configure.tgt for generic a.out

[Gunther Nikl <gnikl at users dot sourceforge dot net>]

Alan Modra wrote:
> On Fri, Jul 02, 2010 at 08:23:58AM +0200, Gunther Nikl wrote:
>> What am I missing here?
> 
> That your assembler does not work reliably, perhaps?

Mhm, so you are suspecting (possible serious?) differences? This is
a bit surprising for me since configure.tgt lists m68k a.out targets
which use BFD.

> Are you sufficiently interested in m68k-aout to spend the time
> verifying that a BFD based assembler is at least as good an option
> for users as an older binutils where m68k-aout was still supported?

My primary interest is not m68k-aout, it is a m68k target using a.out
as its primary object code format. The target is not part of binutils,
thus I used m68k-aout to check current behaviour of weak symbol
handling.

FWIW, I was sufficiently motivated and compared GAS from binutils 2.20
with non-BFD as well as BFD based GAS from binutils 2.9.1. This might
look odd, but the m68k backend in that 2.9.1 is almost up-to-date
because I merged relevant changes from CVS (I omitted CF and MRI
changes). There are some more backports eg. to make the code build
with "modern" GCC and/or on "modern" systems.

I used GCC 4.5.0 to cross-build a m68k-amigaos hosted binutils 2.20
which was configured for m68k-aout as target. The generated object
files by the BFD-based assemblers were identical. Between the object
files generated by the non-BFD GAS and the object files generated by
a BFD-based GAS was only one difference: Some object files generated
by the BFD-based assembler have a bigger BSS size in the a.out header:

   text	   data	    bss	    dec	    hex	filename
  27276	      0	     12	  27288	   6a98	.291/bfd/aout32.o
  27276	      0	     16	  27292	   6a9c	.220/bfd/aout32.o
  10336	      0	     28	  10364	   287c	.291/bfd/archive.o
  10336	      0	     32	  10368	   2880	.220/bfd/archive.o
  19488	     24	    204	  19716	   4d04	.291/bfd/ieee.o
  19488	     24	    208	  19720	   4d08	.220/bfd/ieee.o
  11024	      0	     28	  11052	   2b2c	.291/bfd/linker.o
  11024	      0	     32	  11056	   2b30	.220/bfd/linker.o
   5184	      0	  16388	  21572	   5444	.291/bfd/opncls.o
   5184	      0	  16392	  21576	   5448	.220/bfd/opncls.o
   4024	      0	    260	   4284	   10bc	.291/bfd/tekhex.o
   4024	      0	    264	   4288	   10c0	.220/bfd/tekhex.o

The reason for this difference is that .lcomm increases the section
alignment (as power of 2) of the BSS segment from 2 to 3 and this
information is stored by write.c/record_alignment(). Finally
tc-m68k.c/md_section_align uses that alignment to compute a rounded
section size. This only done for a BFD-based assembler. The non-BFD
assembler installs precomputed section sizes verbatim. IMHO the
difference in the BSS section size is only a minor deviation.

Of course this was only a test of one single program. However, I
think that is a good indication that generic m68k-aout with a
BFD-based assembler is usable as a replacement for older binutils.


Regards,
Gunther