Last year, I briefly discussed the subtleties of
inter-fragment section padding,
and noted that the incremental linker is a common source of this padding.
Commenter DanStur wondered
why the incremental linker inserts padding between section fragments.
The goal of the incremental linker is to permit rapid generation of
a new binary given an old binary and a small number of changes,
so that only a relatively small number of bytes in the binary need
to be modified.
Among other things, the linker adds padding in places that would
permit it to accommodate objects that change size.
For example, the incremental linker adds padding after each function
(which is represented as a code section fragment).
That way, if you make a change to the function that causes it to
become a little bit bigger,
the linker can plop the modified function into the space used by
the original function and its padding,
and it’s done.
Not only did the function’s start address not change,
neither did the start addresses of any other functions change.
This means that the linker doesn’t have to chase down all the
places that call a function and update the target addresses.
The incremental linker does the same thing with data section fragments.
If your object file declares 16 bytes of data,
the incremental linker will add padding after each data fragment.
If you add a new variable to the source file,
the incremental linker can put it in the padding
(assuming there’s room).
This means that the linker doesn’t need to move any
data variables around,
which means that no data addresses need to be updated.
Section fragment padding is just a special case of object padding.
In the case of a section fragment holding data,
if you add a new variable to the section fragment,
and the new variable fits inside the padding,
then the linker can just plop the new variable into the
padding and not have to move any existing data around.
If the linker cannot accommodate the change with the
existing padding, then it has to perform a lot more work
to re-link the program and update all the addresses.
But the linker will add new padding to the re-linked
program, so as to improve the likelihood that the next link
request can be performed incrementally if the change is minor.