Storage layout of primitive types
Summary
Since commit be5d74ca a couple of test cases fail on S/390. At least some of them look like endian related bugs. For example, running fed001
we observe for function rts_getInt32
HsInt32
rts_getInt32 (HaskellObj p)
{
// See comment above:
// ASSERT(p->header.info == I32zh_con_info ||
// p->header.info == I32zh_static_info);
return (HsInt32)(HsInt)(UNTAG_CLOSURE(p)->payload[0]);
}
that the actual integer passed in structure member payload resides in the high part for big endian platform S/390. Thus, reading 8 bytes and then truncating them to the low 4 bytes results in a wrong integer.
-
I'm wondering what the supposed memory layout of primitive types is? For data less than
sizeof(HsInt)
bytes should it be left or right aligned in payload? -
If it was not intended to change placement of content in payload from low to high part for big endian platforms, then has someone an idea where to look for the creation side of the Haskell integer object? That would then need an endian independent implementation.