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: Thu, 31 Aug 2006 08:41:45 +0200
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 30 Aug 2006 23:41:45 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C11B78F2.1845%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: <44F41BB5.76E4.0078.0@xxxxxxxxxx> <C11B78F2.1845%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> 30.08.06 18:18 >>>
>On 29/8/06 9:49 am, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
>> 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.
>Depending how smart the script is, if it tracks required offset of fields in
>the structure definitions it is creating, it could insert explicit padding
>to force the required alignment.

In my opinion that would be too much smartness (and too much complexity
to maintain) for a compatibility solution.

>As for ensuring sysctl/domctl alignments are same for 32- and 64-bit builds,
>we'd anyway like a script that would generate a C program that would print
>field offsets/sizes for all public structures anyway (so that we can be sure
>that none change and break the ABI). If we had that, we could compile the C
>program -m32 and -m64 for sysctl.h and domctl.h and ensure the outputs are
>identical. I think this would be an ideal solution -- but it does assume
>existence of a tool that doesn't exist. :-)

I like that, and would be willing to try to derive such a mechanism from the
scripts I'm already having to deal with the public headers (once that larger
piece of work is [mostly] done).

>Alternative is to say 'screw it' and just treat the sysctl/domctl headers
>like any other, and remove the explicit alignment stuff before we fork
>3.0.3. Domctl in particular is a *big* interface though, so it'd be nice to
>avoid needing to generate (much) compat code for it.



Xen-devel mailing list