Re: [Xen-devel] uint64_aligned_t not compatible across gcc versions

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

>>> Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> 30.08.06 18:18 >>>
>On 29/8/06 9:49 am, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
>
>> One more point here: The addition of this type and XEN_GUEST_HANDLE_64(),
>> as it turns out, makes things more complicated/unreliable in the 
>> compatibility
>> stuff rather then helping the situation: Since we need to force 4-byte
>> alignment on uint64_t (and possible derived types) fields, we have to use
>> #pragma pack() framing the entire (generated) compatibility headers.
>> However, #pragma pack() takes precendence over attribute((aligned())), and
>> hence there is no easy way to force 8-byte alignment on uint64_aligned_t
>> fields.
>
>Depending how smart the script is, if it tracks required offset of fields in
>the structure definitions it is creating, it could insert explicit padding
>to force the required alignment.

In my opinion that would be too much smartness (and too much complexity
to maintain) for a compatibility solution.

>As for ensuring sysctl/domctl alignments are same for 32- and 64-bit builds,
>we'd anyway like a script that would generate a C program that would print
>field offsets/sizes for all public structures anyway (so that we can be sure
>that none change and break the ABI). If we had that, we could compile the C
>program -m32 and -m64 for sysctl.h and domctl.h and ensure the outputs are
>identical. I think this would be an ideal solution -- but it does assume
>existence of a tool that doesn't exist. :-)

I like that, and would be willing to try to derive such a mechanism from the
scripts I'm already having to deal with the public headers (once that larger
piece of work is [mostly] done).

>Alternative is to say 'screw it' and just treat the sysctl/domctl headers
>like any other, and remove the explicit alignment stuff before we fork
>3.0.3. Domctl in particular is a *big* interface though, so it'd be nice to
>avoid needing to generate (much) compat code for it.

Agreed.

Jan

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