[Xcb] compiler padding and sync extension

Josh Triplett josh at joshtriplett.org
Wed Aug 19 08:19:36 PDT 2009


On Tue, Aug 18, 2009 at 10:31:28PM -0500, Aaron Young wrote:
> >> I'm no expert, but I was a little surprised to discover that XCB
> >> structures weren't already defined with __attribute__ ((packed)),
> >> #pragma pack(1), etc.  Any reason this approach hasn't been adopted?
> >> Does the sync extension not get enough use to warrant fixing this?
> >
> > This does need fixing.  The question becomes: how do we fix it
> > optimally?  As I understand it, __attribute__((packed)) makes GCC
> > generate fairly terrible code sometimes; we'd need to check if it does
> > so in this case.  That would in any case only solve the problem for GCC.
> > The "solution" of #defining a wire size for structures that disagrees
> > with sizeof seems even worse, though; on the other hand, given that many
> > structures have variable-length fields afterward that make sizeof less
> > useful to the client app, maybe the pain would remain confined to XCB's
> > accessor functions.
> 
> My understanding (which is certainly limited and probably flawed) is
> that performance issues would only arise in situations where the
> compiler would have previously (before using #pragma pack) padded
> certain parts of a structure in order to simplify member access code.
> However, if the compiler was previously doing this, that means those
> situations are potentially broken anyway as the padding would have
> caused the memory representation of those structures to deviate from
> the protocol.

I don't know for sure either, and GCC may have improved since I learned
this, but at one point I think __attribute__((packed)) would cause GCC
to use slow methods for structure access even on properly aligned
fields.  In part, I think this comes about because GCC no longer assumes
that the structure in memory must start on a reasonably aligned
boundary, and thus even a 4-byte value starting at a 4-byte-aligned
offset from the beginning of the structure might not have a
4-byte-aligned address in memory.  GCC doesn't know that the X protocol
always keeps fields naturally aligned.

- Josh Triplett


More information about the Xcb mailing list