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

[Xen-devel] Re: [PATCH] Re: [Xen-staging] [xen-unstable] Explicitly tag

To: Alex Williamson <alex.williamson@xxxxxx>
Subject: [Xen-devel] Re: [PATCH] Re: [Xen-staging] [xen-unstable] Explicitly tag every anonymous aggregate in the public headers.
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Fri, 28 Mar 2008 21:47:53 +0000
Cc: xen-ia64-devel <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx>
Delivery-date: Fri, 28 Mar 2008 14:48:58 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1206738267.7320.43.camel@lappy>
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: AciRHV/0nqF4Gv0QEdycwgAWy6hiGQ==
Thread-topic: [PATCH] Re: [Xen-staging] [xen-unstable] Explicitly tag every anonymous aggregate in the public headers.
User-agent: Microsoft-Entourage/11.4.0.080122
On 28/3/08 21:04, "Alex Williamson" <alex.williamson@xxxxxx> wrote:

>    My previous fix allowed this to build on ia64, but it turns out
> there's still a boot issue that I don't understand.  As is, we take a
> nested dtlb fault on boot, which hg bisect determines is caused by this
> patch.  From a simple test program, I can verify that only the outermost
> __extension__ is necessary to include code w/ -std=c99.  So embedding an
> __extension__ within an __extension__ isn't necessary, but I don't know
> why it actually changes the behavior of the code.  The patch below
> reverts a few chucks of this cset and gets us booting again.  FWIW, I'm
> using gcc-4.1.2.  Thanks,

Playing around with this a bit I can't see what changes for having nested
usage of __extension__. I'm using gcc 4.1 but on x86_64.

Could you play around with sizeof() and offsetof() and find out exactly
what's getting laid out differently? Maybe we'll have to do some of the
reversion that you suggest (or just revert the whole lot and assert __GNUC__
and !__STRICT_ANSI__ at the top of the file). But it'd be nice to know a bit
more about what's going on here.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel