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: Jan Beulich <jbeulich@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] uint64_aligned_t not compatible across gcc versions
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Mon, 28 Aug 2006 16:02:06 +0100
Delivery-date: Mon, 28 Aug 2006 08:11:50 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <44F31DE2.76E4.0078.0@xxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcbKsu0/K8fsujamEdu6SQANk04WTA==
Thread-topic: [Xen-devel] uint64_aligned_t not compatible across gcc versions
User-agent: Microsoft-Entourage/
On 28/8/06 3:46 pm, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

> gcc up to 3.3.x doesn't honor __attribute__((__aligned(..))) on typedef-s (and
> in my opinion this was the correct behavior, as a typedef and its original
> type
> must be fully exchangeable in all their uses). For this reason, I'd recommend
> changing the definition of this type on x86_32 with below patch.

Thanks, I did wonder.

> Further looking into how it is being used and therefore into the uses of
> XEN_GUEST_HANDLE_64 I am not really clear about the intentions of that
> macro and its companions: Reserving a 64-bit slot for a pointer would seem
> nice for doing the compatibility layer, but turns out useless if the 32-bit
> native implementation doesn't check the upper half of passed in values, as
> that implies that the 64-bit compatibility layer must not assume these upper
> bits are all zero or else it wouldn't be binary compatible.

Yes, the aim is to avoid the need for a 32-on-64 shim for the domctl and
sysctl hypercalls. I guess we'll end up with a semi-automated scheme for the
other hypercalls anyway, but since we don't guarantee compatibility on those
interfaces we may as well make our lives as easy as possible.

Guest handle fields are *only* written by the set_xen_guest_handle() macro
in the tools -- you'll see that I modified that macro to zap the high bits
if the field is 8 bytes. This should be sufficient?

 -- Keir

Xen-devel mailing list