LKML Archive on
help / color / mirror / Atom feed
From: "Phil Endecott" <>
To: <>
Subject: Subtleties of __attribute__((packed))
Date: Wed, 06 Dec 2006 13:20:41 +0000	[thread overview]
Message-ID: <> (raw)

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;a=blobdiff;h=1a7a3f50e40b0a956f44511e42b124a6be98b30b;hp=74f6889f834f1679f09ccd8bbc772fdafd6aade2;hb=e2bf2e26c0915d54208315fc8c9864f1d987217a;f=arch/powerpc/platforms/iseries/main_store.h 

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:


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!



(You are welcome to cc: me with any replies.)

             reply	other threads:[~2006-12-06 13:20 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-06 13:20 Phil Endecott [this message]
2006-12-06 14:01 ` Subtleties of __attribute__((packed)) Frederik Deweerdt
2006-12-06 14:24   ` Phil Endecott
2006-12-06 15:04 ` Jan Blunck
2006-12-06 15:22   ` Phil Endecott
2006-12-06 15:54     ` Jan Blunck
2006-12-06 16:02       ` Andreas Schwab
2006-12-06 16:41         ` Jan Blunck
2006-12-06 17:28           ` Andreas Schwab
2006-12-06 16:13       ` Phil Endecott
2006-12-06 16:26         ` Jan Blunck
2006-12-06 17:54       ` Russell King
2006-12-06 18:05         ` David Miller
2006-12-07  9:48         ` Jan Blunck
2006-12-07 10:30           ` Andreas Schwab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).