堆栈变量是否由 GCC__ 属性__ ((对齐(x))对齐?

我有以下密码:

#include <stdio.h>


int
main(void)
{
float a[4] __attribute__((aligned(0x1000))) = {1.0, 2.0, 3.0, 4.0};
printf("%p %p %p %p\n", &a[0], &a[1], &a[2], &a[3]);
}

我有以下输出:

0x7fffbfcd2da0 0x7fffbfcd2da4 0x7fffbfcd2da8 0x7fffbfcd2dac

为什么 a[0]的地址不是 0x1000的倍数?

__attribute__((aligned(x)))到底是做什么的? 我误解了 这个的解释?

我用的是 gcc 4.1.2。

79820 次浏览

I believe the problem is that your array is on the stack, and that your compiler is too old to support over-aligned stack variables. GCC 4.6 and later fixed that bug.

C11/C++11 alignas(64) float a[4]; Just Works for any power of 2 alignment.
So does the GNU C __attribute__((aligned(x))) as you were using it.

(In C11, #include <stdalign.h> for the #define alignas _Alignas: cppref).


But in your case of a very large alignment, to a 4k page boundary, you may not want it on the stack.

Because the stack pointer could be anything when the function starts, there is no way to align the array without allocating a lot more than you need and adjusting it. (Compilers will and rsp, -4096 or equivalent and not use any of the 0 to 4088 bytes that allocated; branching on whether that space is large enough or not would be possible but isn't done because huge alignments much larger than the size of the array or other locals are not the normal case.)

If you move the array out of the function and into a global variable, it should work. The other thing you could do is keep it as a local variable (which is a very good thing), but make it static. This will prevent it from being stored on the stack. Beware that both of these ways are not thread-safe or recursion-safe, since there will be only one copy of the array.

With this code:

#include <stdio.h>


float a[4] __attribute__((aligned(0x1000))) = {1.0, 2.0, 3.0, 4.0};


int
main(void)
{
printf("%p %p %p %p\n", &a[0], &a[1], &a[2], &a[3]);
}

I get this:

0x804c000 0x804c004 0x804c008 0x804c00c

which is what is expected. With your original code, I just get random values like you did.

Alignement is not effective for all types. You should consider using a structure to see the attributes in action:

#include <stdio.h>


struct my_float {
float number;
}  __attribute__((aligned(0x1000)));


struct my_float a[4] = { {1.0}, {2.0}, {3.0}, {4.0} };


int
main(void)
{
printf("%p %p %p %p\n", &a[0], &a[1], &a[2], &a[3]);
}

And then, you'll read:

0x603000 0x604000 0x605000 0x606000

Which is what you were expecting.

Edit: Pushed by @yzap and following @Caleb Case comment, the initial problem is due to GCC version only. I've checked on GCC 3.4.6 vs GCC 4.4.1 with the requester's source code:

$ ./test_orig-3.4.6
0x7fffe217d200 0x7fffe217d204 0x7fffe217d208 0x7fffe217d20c
$ ./test_orig-4.4.1
0x7fff81db9000 0x7fff81db9004 0x7fff81db9008 0x7fff81db900c

It's now obvious that older GCC versions (somewhere before 4.4.1) shows alignment pathologies.

Note 1: My proposed code doesn't answer the question which I understood as "aligning each field of the array".

Note 2: Bringing non-static a[] inside main() and compiling with GCC 3.4.6 breaks the alignment directive of the array of struct but keeps 0x1000 distance between structs... still bad ! (see @zifre answer for workarounds)

Recent GCC (tested with 4.5.2-8ubuntu4) appear to work as expected with the array aligned properly.

#include <stdio.h>


int main(void)
{
float a[4] = { 1.0, 2.0, 3.0, 4.0 };
float b[4] __attribute__((aligned(0x1000))) = { 1.0, 2.0, 3.0, 4.0 };
float c[4] __attribute__((aligned(0x10000))) = { 1.0, 2.0, 3.0, 4.0 };


printf("%p %p %p %p\n", &a[0], &a[1], &a[2], &a[3]);
printf("%p %p %p %p\n", &b[0], &b[1], &b[2], &b[3]);
printf("%p %p %p %p\n", &c[0], &c[1], &c[2], &c[3]);
}

I get:

0x7ffffffefff0 0x7ffffffefff4 0x7ffffffefff8 0x7ffffffefffc
0x7ffffffef000 0x7ffffffef004 0x7ffffffef008 0x7ffffffef00c
0x7ffffffe0000 0x7ffffffe0004 0x7ffffffe0008 0x7ffffffe000c

There was a bug in gcc that caused attribute aligned to not work with stack variables. It appears to be fixed with the patch linked below. The link below also contains quite a bit of discussion for the problem as well.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16660

I have tried your code above with two different versions of gcc: 4.1.2 from a RedHat 5.7 box, and it failed similarly to your problem (the local arrays wre in no way aligned on 0x1000 byte boundaies). I then tried your code with gcc 4.4.6 on RedHat 6.3, and it worked flawlessly (the local arrays were aligned). The Myth TV folks had a similar problem (that the gcc patch above seemed to fix):

http://code.mythtv.org/trac/ticket/6535

Anyway, it looks like you found a bug in gcc, that appears to be fixed in later versions.