This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Misleading error message from gas/configure.tgt for generic a.out
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