[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] uint64_aligned_t not compatible across gcc versions
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. 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. :-) 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. -- Keir > (a) exclude sysctl.h and domctl.h from the processing (which is probably > intended, but opens the possibility of unintentionally introducing fields of > types that need translation, which would go undetected at build time), and > (b) assume that no other header uses this type, or depends on the 8-byte > alignment forced on __guest_handle_64_XXX. > Both are maintenance-wise bad in my opinion. Ideas? _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |