Hi!
I think that is caused by the implicit padding caused by the reference
counter inside each NSObject. Basically memory is allocated for the
reference counter + object size, but the reference counter is located at
the start of the allocated memory chunk, so you get a pointer offset by
the amount of bytes the reference counter needs. malloc returns a 16
byte aligned address, the first few bytes of the chunk are needed for
the reference counter which has the size of an unsigned long, meaning 8
byte on Linux/AMD64, so you end up with a pointer pointing to the memory
after the reference counter, which is the 16 byte aligned address + 8 bytes.
Cheers,
TOM
On 2013-07-05 15:09, Laurent Michel wrote:
Good morning!
I have ported an application to GNUstep (from MacOS) and everything
works very well on a ubuntu 12.04 LTS (32-bit).
However, the same port fails under 12.04 LTS (64-bit) for a simple reason:
On GNUstep the NSAllocateObject function (and therefore all the alloc
methods) do _not_ return
16 bytes aligned objects. On Linux, the objects are always 8 bytes
aligned. I checked, and my code on Cocoa (MacOS 10.8.4) [the same call
to NSAllocateObject] returns 16 bytes aligned objects.
Either this is a bug, or I'm missing a macro/define somewhere to tell
GNUstep I'd like to have 16 bytes aligned objects.
Naturally, I can redefine a new method for the meta-class whose
instances require a 16 byte alignment, but this is ad-hoc and would be
required for every object susceptible of storing a structure expecting
16 bytes alignments.
Note that the structure whose field require a 16 byte alignment and
which is hosted in instances of that specific class is correctly
tagged with a clang attribute to require that the structure start
address be correctly aligned. Of course, that _assumes_ that the
object itself is 16 bytes aligned which is not the case here.
Is there a suitable incantation to get a 16-byte alignment on Linux64
? Do you agree that this is a bug ?
Thanks for your help,
All the best,
--
Laurent
_______________________________________________
Gnustep-dev mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
_______________________________________________
Gnustep-dev mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
