Bug#642762: xulrunner-6.0: console flooded with unaligned access messages on ia64 (IA-64/IPF/Itanium) platform

Mike Hommey mh at glandium.org
Thu Oct 6 05:50:32 UTC 2011


On Thu, Oct 06, 2011 at 12:21:29AM +0200, Émeric Maschino wrote:
> OK, reading http://www.osronline.com/ddkx/kmarch/64bitamd_20iv.htm
> helped me understand structure alignment (well, I think!): "The
> alignment of the beginning of a structure or a union is the maximum
> alignment of any individual member."
> 
> > 2011/10/5 Mike Hommey <mh at glandium.org>:
> > On Wed, Oct 05, 2011 at 10:50:56AM +0200,
> >
> > The problem is not the alignment of m2, the problem is the alignment of
> > the whole struct, which has a requirement of 32-bits. Which means a
> > struct nsID can end up at 0x0, 0x4, 0x8, or 0xc. When it's at 0x4 or
> > 0xc, it can't be casted to a 64-bits word, because that's not 64-bits
> > aligned. There are two solutions: make sure struct nsIDs are 64-bits
> > aligned, or change the Equals function to use 2 32 bits words
> > comparisons.
> 
> So, in order to have nsID 64-bit aligned, is simply inserting a
> PRUint64 dummy internal data the way to enforce 64-bit alignment?
> 
> struct nsID {
>   PRUint64 dummy;
>   PRUint32 m0;
>   PRUint16 m1;
>   PRUint16 m2;
>   PRUint8 m3[8];
> };

That would waste a 64-bits word. The usual way to do it is to use
unions:
union {
  PRUint64 dummy;
  struct {
    PRUint32 m0;
    PRUint16 m1;
    PRUint16 m2;
  };
};

Mike





More information about the pkg-mozilla-maintainers mailing list