Sorry, I noticed just now that here you are discussing about the problem with the compilation of libvirt on ARM platforms. An alternative solution can be ATTRIBUTE_PACKED. I've sent right now to the ML a patch based on this. Michele On 12/12/2013 17:11, Daniel P. Berrange wrote:
On 12/11/2013 12:15 PM, Eric Blake wrote:
struct _virObjectEvent { virObject parent; int eventID; virObjectMeta meta; };
Only has alignment specified by virObject (which in turn is unsigned int, int, void*), struct _virObject { unsigned int magic; int refs; virClassPtr klass; };
I think one possible solution would be as simple as altering src/util/virobject.h to change 'magic' from 'unsigned int' to 'unsigned long long' - then ALL virObject structs will be forcefully aligned to the worst case between void* and long long, so that any subclass can use long long without requiring stricter alignment than the parent class, and so that downcasting code like domain_event.c no longer warns. But it does make every object consume more memory on 64-bit platforms (from 16 bytes into 24 bytes), is that okay? Or maybe even change _virObject to contain a union:
struct _virObject { union { long long align; struct { unsigned int magic; int refs; } s; } u; virClassPtr klass; }
which keeps the size at 16 bytes on 64-bit platform, keeps things at 12 bytes on 32-bit platforms that don't care about long long alignment, and for ARM (*) would change things from 12 to 16 bytes with 8-byte alignment for the long long.
Yeah, that means using obj->u.s.refs instead of obj->refs, but most code shouldn't be directly mucking with object-internal fields, so hopefully the fallout would be limited to just virobject.c (if only C99 had anonymous struct/unions; C11 does, but we don't require that yet).
(*) Am I correct that your platform with the compile failure is a 32-bit ARM platform with 4-byte pointers? Because if it were 64-bit, then I would have guessed that an 8-byte pointer would already be forcing 8-byte alignment, such that use of 'long long' in a subclass wouldn't be warning about changed alignment. That seems reasonable to me - it makes sense that we should have our base object type be nicely aligned, instead of trying to fix
On Wed, Dec 11, 2013 at 12:28:32PM -0700, Eric Blake wrote: this in the events code (and potentially anywhere else using objects in the future).
Daniel
-- *Michele Paolino*, Virtualization R&D Engineer Virtual Open Systems /Open Source KVM Virtualization Developments/ /Multicore Systems Virtualization Porting Services/ Web/:/www.virtualopensystems. <http://www.virtualopensystems.com/>com <http://www.virtualopensystems.com/>