[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 4/4] xen/arm: correctly handle an empty array of platform descs.

On Fri, 2013-05-17 at 16:34 +0100, Jan Beulich wrote:
> >>> On 17.05.13 at 16:34, Ian Campbell <ian.campbell@xxxxxxxxxx> wrote:
> > On Fri, 2013-05-17 at 11:39 +0100, Jan Beulich wrote:
> >> >> And btw., for both 32- and 64-bit ARM, other than for x86, I see
> >> >> empty structure instances occupy zero bytes (and hence distinct
> >> >> symbols end up at the same address), so the compiler is conflicting
> >> >> with itself here.
> >> > 
> >> > I imagine this is as much to do with the architecture ABI as the
> >> > compiler.
> >> 
> >> So do I, but this doesn't make this any less of a compiler bug.
> > 
> > Is there a requirement (e.g. from the C standard) that an empty struct
> > take at least one byte, or more likely I suppose something about
> > different instances having different addresses which sort of implies it?
> Yes: "Two pointers compare equal if and only if both are null pointers,
> both are pointers to the same object (including a pointer to an object
> and a subobject at its beginning) or function, both are pointers to one
> past the last element of the same array object, or one is a pointer to
> one past the end of one array object and the other is a pointer to the
> start of a different array object that happens to immediately follow
> the first array object in the address space."

Right, that rings a bell, thanks.

Even on x86 I see this:

        struct foo { };
        static struct foo a, b;
        int main(void)
                printf("a %p %lx\n", &a, (unsigned long)&a);
                printf("b %p %lx\n", &b, (unsigned long)&b);
                printf("a and b are %s\n", &a == &b ? "equal" : "distinct");
                printf("ulong a and b are %s\n", (unsigned long)&a == (unsigned 
long)&b ? "equal" : "distinct");

        $ gcc --version
        gcc (Debian 4.7.2-5) 4.7.2
        $ gcc -O2 t.c
        $ ./a.out
        a 0x60094c 60094c
        b 0x60094c 60094c
        a and b are distinct
        ulong a and b are distinct
and I see the same thing on arm32 and visibility has no affect.

This seems to conform to what you quote above even though the addresses
appear equal.

I was a bit surprised about the casted result...

(I can't quite shake the feeling I've done something stupid here...)


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.