Is it possible to remove section padding from in as/ld?

Vincent Rivière vincent.riviere@freesbee.fr
Sat May 15 10:56:00 GMT 2010


Miro Kropacek wrote:
> Is it possible to remove section padding from in as/ld?

Hello.

You are using the m68k-atari-mint target, similar to m68k-netbsd, using the 
a.out file format.

First, the default linker script I have embedded for that target does not 
add any additional alignment. It only concatenates the sections found in 
input files. So there is no problem with ld.

Your problem is the default aligment for sections in object files.

Let's say you assemble a single nop, opcode 0x4e71.

$ m68k-atari-mint-objdump.exe -s nop.o

nop.o:     file format a.out-zero-big

Contents of section .text:
  0000 4e710000                             Nq..

You see the opcode has been padded with an additional 0x0000 just after. Why ?

$ m68k-atari-mint-objdump.exe -h nop.o

nop.o:     file format a.out-zero-big

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

The important thing is the Algn column. The value "2**2" means "2 power 2", 
thus 4 bytes. If I'm not wrong, for a.out object files the section alignment 
value is not stored into the file, it is hardcoded into the binutils. So the 
only way to respect that alignment in the final executable is to pad all 
sections to that alignment. The padding described above seems to be useless, 
but it will be useful if the next section starts with .balign 4.

And this is the big reason for these fillers: to honor the .balign 4 
directive, which matters on 68020+.

However, I'm very disappointed because personally I care only about the old 
68000 for which an alignment of 2 bytes is always enough. So in a 68000 
executable, there is an average loss of 1 byte per object file.
Ideally, the binutils should be able to produce 2**1 sections when -m68000 
is used, and 2**2 sections for 68020+. I don't know if this is possible.

Some years ago, I used the attached patch to change the default hardcoded 
alignment to 2**1. The only change is the exponent in the macro. And it is 
the answer to your question.

Today, I see that this macro is used for all m68k architectures, we could 
try to change the exponent for 68000 only, it may do exactly what we need. 
But I wonder how objdump would behave.

-- 
Vincent Rivière
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: align.diff
URL: <https://sourceware.org/pipermail/binutils/attachments/20100515/da0b1620/attachment.ksh>


More information about the Binutils mailing list