This is the mail archive of the
mailing list for the binutils project.
Re: Can this be right?
- From: mike stump <mrs at windriver dot com>
- To: schwab at suse dot de
- Cc: binutils at gcc dot gnu dot org
- Date: Fri, 26 Apr 2002 14:53:00 -0700 (PDT)
- Subject: Re: Can this be right?
- References: <email@example.com>
> To: mike stump <firstname.lastname@example.org>
> Cc: email@example.com
> From: Andreas Schwab <firstname.lastname@example.org>
> 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
I have these types of tools in our product. One such tool is gdb.
..kankakee bash objdump68k -h t.o
t.o: file format a.out-sunos-big
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
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.