Can this be right?

Can this be right?

[mike stump]

Can this be right (from src/binutils/src/gas/config/tc-m68k.c):

void
md_begin ()
{
[ ... ]
#ifdef OBJ_ELF
  record_alignment (text_section, 2);
  record_alignment (data_section, 2);
  record_alignment (bss_section, 2);
#endif
}

?

Surely this is required for a.out also?  I expected ELF to be smarter
about alignments making the above unnecessary?  A quick check of other
files indicates that elf systems often do this, well, ok, and a quick
check of what seem to be aout systems seem to do this as well.

If one has:

.balign 1
.byte 1

in 3 files, and then a:
.balign 4
.byte 2

then on an aout m68k system, the `2' comes out on the wrong address.

Can we make this unconditional?

Re: Can this be right?

[Andreas Schwab]

mike stump <mrs@windriver.com> writes:

|> Can this be right (from src/binutils/src/gas/config/tc-m68k.c):
|> 
|> void
|> md_begin ()
|> {
|> [ ... ]
|> #ifdef OBJ_ELF
|>   record_alignment (text_section, 2);
|>   record_alignment (data_section, 2);
|>   record_alignment (bss_section, 2);
|> #endif
|> }
|> 
|> ?
|> 
|> Surely this is required for a.out also?  I expected ELF to be smarter
|> about alignments making the above unnecessary?  A quick check of other
|> files indicates that elf systems often do this, well, ok, and a quick
|> check of what seem to be aout systems seem to do this as well.
|> 
|> If one has:
|> 
|> .balign 1
|> .byte 1
|> 
|> in 3 files, and then a:
|> .balign 4
|> .byte 2
|> 
|> then on an aout m68k system, the `2' comes out on the wrong address.
|> 
|> 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.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

Re: Can this be right?

[Alan Modra]

On Fri, Apr 26, 2002 at 01:06:16PM -0700, mike stump wrote:
> Can we make this unconditional?

Makes sense to me.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre