Alexey Neyman wrote:
> I ran into the following problem using gcc: I am using some structures,
> which are put into a dedicated section. The linker concatenates these
> sections from all files; I have a linker script which assigns symbols
> to the start and end of this section. When I need to traverse all these
> structures, I then use the following loop:
>
> struct somename *p;
> for (p = &__start_section; p < &__end_section; p++) {
> ...
>
> All worked well when the size of the structure was below 32 bytes. When
> I added an additional field, GCC suddenly started aligning each
> structure to 32 bytes - so the structures in this section are padded to
> 32-byte boundary. As the size of the structure is 36 bytes, though, the
> loop above breaks on the 2nd element: it tries to access it at
> &__start_section + 36, while the structure is actually at
> &__start_section + 64.
>
> I narrowed it down to the following example:
>
> <<<
> struct {
> int xxx[NINT];
> } aaa __attribute__((section(".foo")));
> <<<<
Please try making it a one-element array of that struct. Does that
fix your problem?
> When compiled, GCC selects the following alignments:
>
> $ gcc -o - -S gg.c -DNINT=7 | grep align
> .align 4
> $ gcc -o - -S gg.c -DNINT=8 | grep align
> .align 32
> $ gcc -o - -S gg.c -DNINT=9 | grep align
> .align 32
>
> That's especially strange since __alignof__ reports the alignment of
> this structure as 4. It seems natural that the size of the structure
> should be a multiple of its alignment.
Indeed.
> For now, I circumvented it by adding __attribute__((aligned(4))) to
> these structures. However, it may not be good if this structure gets a
> new member which would have a 8-byte alignment.
>
> The question is, why does GCC perform such 32-byte alignment and is it
> possible to turn off such behavior globally?
What target is this? It might be an ABI requirement, or just an optimization.
Strictly speaking, gcc is allowed to do this.
Andrew.
