Can this be right?

[mike stump]

> To: mike stump <mrs@windriver.com>
> Cc: binutils@gcc.gnu.org
> From: Andreas Schwab <schwab@suse.de>
> Date: Fri, 26 Apr 2002 22:58:56 +0200

> |> Can we make this unconditional?

> I can't remember from the m68k-linux-aout times that this ever was a
> problem.  a.out doesn't record any alignment in the object file, so it
> shouldn't matter anyway.  Don't know about COFF, but the situation might
> be similar.

Ah, let me rephrase this a little.  The past behavior was to round out
sizes for .o files to 4x.  The new behavior is to only go to 1x.  Old
tools that use .o files that don't deal well with 1x die.  It is safe
to round the size up in the assembler, as the linker would have to do
it anyway.

I have these types of tools in our product.  One such tool is gdb.

..kankakee bash[107] objdump68k -h t.o

t.o:     file format a.out-sunos-big

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000001  00000000  00000000  00000020  2**2
                  CONTENTS, ALLOC, LOAD, CODE
  1 .data         00000001  00000001  00000001  00000021  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00000000  00000002  00000002  00000000  2**2
                  ALLOC

As you can see from a dump, objdump is yet another one of those tools
that gets just a bit confused.  VMA&3 should == 0.  By making the code
unconditional we fixes these sorts of problems.

Hoping that I don't have to carry this as a local change until we dump
the m68k-aout config.