Dear All,
I used to think that this:
struct foo {
int a __attribute__((packed));
char b __attribute__((packed));
... more fields, all packed ...
};
was exactly the same as this:
struct foo {
int a;
char b;
... more fields ...
} __attribute__((packed));
but it is not, in a subtle way.
Maybe you experts all know this already, but it was new to me so I
thought I ought to share it, since there have been a few patches
recently changing the first form to the second form to avoid gcc
warnings. (See for example
http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blobdiff;h=1a7a3f50e40b0a956f44511e42b124a6be98b30b;hp=74f6889f834f1679f09ccd8bbc772fdafd6aade2;hb=e2bf2e26c0915d54208315fc8c9864f1d987217a;f=arch/powerpc/platforms/iseries/main_store.h
or http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6a878184c202395ea17212f111ab9ec4b5f6d6ee)
The difference comes when you declare a variable of this struct type
like this:
char c;
struct foo f;
If you use the first form in the declaration of struct foo, a gap will
be left between c and f so that the start of the struct is aligned.
But if you use the second form, f will be packed immediately after c, unaligned.
On x86 of course none of this matters for correct behaviour since the
hardware supports unaligned accesses. Assuming that your hardware
doesn't do unaligned accesses then some code will still work. In
particular, if you access f like this:
f.a++;
or probably
func1(f.a); // func1 takes an int
then gcc will generate the necessary byte-shuffling code. However, if
you write this:
func2(&f.a); // func2 takes an int*
then an unaligned pointer is passed to func2. When func2 dereferences
the pointer the hardware fails in some way.
GCC does not seem to generate an error or warning when you take the
address of an unaligned field like this.
I believe that the solution is to write something like this:
struct foo {
int a;
char b;
... more fields ...
} __attribute__((packed)) __attribute__((aligned(4)));
Now the fields within the struct will be packed, but variables of the
struct type will be aligned to a 4-byte boundary.
It could be that the kernel code is all safe. I discovered this issue
in user code that used structs from the kernel headers. But I
encourage anyone who changed their use of __attribute__((packed)) to
avoid a gcc warning to review what they have done, especially if they
have tested it only on x86.
Thanks for your attention, and please forgive me if you all know all
this already!
Regards,
Phil.
(You are welcome to cc: me with any replies.)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
