WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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/11.2.5.060620
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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel