This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] uint64_aligned_t not compatible across gcc versions

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] uint64_aligned_t not compatible across gcc versions
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Tue, 29 Aug 2006 10:49:25 +0200
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 29 Aug 2006 01:49:25 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C118CBDA.EB6%Keir.Fraser@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <44F328A7.76E4.0078.0@xxxxxxxxxx> <C118CBDA.EB6%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
One more point here: The addition of this type and XEN_GUEST_HANDLE_64(),
as it turns out, makes things more complicated/unreliable in the compatibility
stuff rather then helping the situation: Since we need to force 4-byte
alignment on uint64_t (and possible derived types) fields, we have to use
#pragma pack() framing the entire (generated) compatibility headers.
However, #pragma pack() takes precendence over attribute((aligned())), and
hence there is no easy way to force 8-byte alignment on uint64_aligned_t
fields. The only option I currently have is to
(a) exclude sysctl.h and domctl.h from the processing (which is probably
intended, but opens the possibility of unintentionally introducing fields of
types that need translation, which would go undetected at build time), and
(b) assume that no other header uses this type, or depends on the 8-byte
alignment forced on __guest_handle_64_XXX.
Both are maintenance-wise bad in my opinion. Ideas?


Xen-devel mailing list