All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@hp.com>
To: Keir Fraser <keir.fraser@eu.citrix.com>
Cc: xen-ia64-devel <xen-ia64-devel@lists.xensource.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Samuel Thibault <samuel.thibault@eu.citrix.com>
Subject: Re: [PATCH] Re: [Xen-staging] [xen-unstable] Explicitly tag every anonymous aggregate in the public headers.
Date: Mon, 31 Mar 2008 09:49:31 -0600	[thread overview]
Message-ID: <1206978571.7735.10.camel@lappy> (raw)
In-Reply-To: <C4131809.1583B%keir.fraser@eu.citrix.com>

On Fri, 2008-03-28 at 21:47 +0000, Keir Fraser wrote:
> On 28/3/08 21:04, "Alex Williamson" <alex.williamson@hp.com> 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.

   Ok, here's what I found out:

# struct xen_ia64_opt_feature with __anonymous_struct:

sizeof(struct xen_ia64_opt_feature): 24
offsetof(struct xen_ia64_opt_feature, pgprot): 16

# without:

sizeof(struct xen_ia64_opt_feature): 32
offsetof(struct xen_ia64_opt_feature, pgprot): 16

The sizeof the struct changes, and it can't possible be 24 bytes if an 8
byte pgprot starts at offset 16 and is followed by another 8 bytes, so
the size is wrong with the __extension__ attribute.

--

# struct mapped_regs with __anonymous_struct:

sizeof(struct mapped_regs): 4096
offsetof(struct mapped_regs, dcr): 2048
offsetof(struct mapped_regs, rsv6): 2048
offsetof(struct mapped_regs, precover_ifs): 3072
offsetof(struct mapped_regs, tmp): 3072

# without:

sizeof(struct mapped_regs): 4096
offsetof(struct mapped_regs, dcr): 2048
offsetof(struct mapped_regs, rsv6): 2704
offsetof(struct mapped_regs, precover_ifs): 3072
offsetof(struct mapped_regs, tmp): 3280

This time the sizeof is correct, and the offset of the first entries in
the struct are correct, but the last entry in the struct is at the same
offset as the first, which is obviously unintended.

It seems pretty clear that in nesting __extension__ attributes in this
manner, the struct is actually ignored and the compiler is treating the
everything that was in the struct as a separate member of the union.  In
the mapped_regs example, the structure size remains correct only because
the union is full padded out using the full size arrays.  Please apply
the patch I sent previously to revert the nested __extension__
attributes.  Thanks,

	Alex

-- 
Alex Williamson                             HP Open Source & Linux Org.

  reply	other threads:[~2008-03-31 15:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200803261016.m2QAGPsq017512@latara.uk.xensource.com>
2008-03-26 15:11 ` [PATCH] Re: [Xen-staging] [xen-unstable] Explicitly tag every anonymous aggregate in the public headers Alex Williamson
2008-03-27 14:37   ` Alex Williamson
2008-03-28 21:04 ` Alex Williamson
2008-03-28 21:47   ` Keir Fraser
2008-03-31 15:49     ` Alex Williamson [this message]
2008-03-31 16:21       ` Keir Fraser
2008-03-31 16:28         ` Alex Williamson
2008-03-28 22:37   ` Keir Fraser
2008-03-28 22:55     ` Alex Williamson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1206978571.7735.10.camel@lappy \
    --to=alex.williamson@hp.com \
    --cc=keir.fraser@eu.citrix.com \
    --cc=samuel.thibault@eu.citrix.com \
    --cc=xen-devel@lists.xensource.com \
    --cc=xen-ia64-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.