Section offset and address alignment in relocatable files

[Florian Weimer]

As far as I read the ELF specification, there is no constraint that
the file offset of a section must be a multiple of the address
alignment.

However, this is not what GAS and the internal Clang assembler
produce. Both ensure alignment of the file offset at section start.

The difference in file size can be quite pronounced in case of large
section alignment, hence my question.

[Ali Bahrami]

I think it's implicit that they should be, but I haven't
tried to justify that by studying the ABI.

Tools that access such files depend on the data being
aligned so that they don't get alignment failures (SIGBUS)
when reading/writing. Even for relocatable objects, the common
way to access them (via libelf), at least for reading, is to
mmap the file, and then access the data directly in memory.

It would be expensive if the data isn't aligned in the file,
because reader/writers will have to copy the data to/from
scratch buffers. We see the same sort of issue in archives,
where "member alignment" can be lower than the alignment needed
by objects. The Solaris libelf has some ugly "member sliding"
logic to align such archive members in memory.

What kind of section alignment are you setting, where the few
bytes lost to alignment are a concern?

- Ali

[Florian Weimer]

* Ali Bahrami:

> What kind of section alignment are you setting, where the few
> bytes lost to alignment are a concern?

I think the garbage collector I plan to interface with needs 2**14
alignment. It doesn't really matter because it's for an ET_REL file.
I was just curious about the actual rules.

[Cary Coutant]

No, there is no such requirement in the ELF spec. It does have a
restriction for sh_addr, but that should really apply only to
executable files (and the spec ought to be a little more explicit
about that).

The spec also has a restriction concerning p_vaddr, p_offset, and
p_align in the program header, which would work its way back to
section placement by implication, but of course would apply only to
executable files.

-cary

[Cary Coutant]

> I think the garbage collector I plan to interface with needs 2**14
> alignment. It doesn't really matter because it's for an ET_REL file.
> I was just curious about the actual rules.

I've seen situations like this on HP-UX, and I'm pretty sure its
assembler and compilers do not force alignment of the sections in the
.o files.

-cary