Noah W wrote:
> I have attached a small test that demonstrates this. The size of the struct
> is 24 bytes. If I place 3 structs in to the section the size calculated by
> the difference between __start_ and __stop_ is 88, 16 more than I would
> expect.
The extra size is the padding added to keep each struct aligned to a 16-
byte boundary as required by the ABI. You can easily see what's going
on by looking at the assembly output that gcc produces with -S:
.file "tc.c"
.section section_test,"aw",@progbits
.align 16
.type entry_C.1557, @object
.size entry_C.1557, 24
entry_C.1557:
.zero 24
.align 16
.type entry_B.1556, @object
.size entry_B.1556, 24
entry_B.1556:
.zero 24
.align 16
.type entry_A.1555, @object
.size entry_A.1555, 24
entry_A.1555:
.zero 24
.text
.globl main
.type main, @function
main:
; and so on...
(Note when visually inspecting the assembly output you can add -fno-
asynchronous-unwind-tables to remove a lot of the clutter, but obviously
don't use that when compiling unless you know that it's safe.)
You can alter the default alignment if you want, e.g.
static struct dummy entry_A __attribute__((section("section_test"), aligned(8)));
static struct dummy entry_B __attribute__((section("section_test"), aligned(8)));
static struct dummy entry_C __attribute__((section("section_test"), aligned(8)));
But that's probably not a great idea because the default alignment
requirement is there to allow the use of sse2 vector instructions that
require aligned operands. By changing the alignment you either prevent
the compiler from using those instructions (if their definition was in
scope at the time) or worse, you risk a runtime illegal instruction
fault if you pass their address to a function that isn't aware of their
changed alignment and assumes it's safe to use vector instructions on
them.
Brian
