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.

1. 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?

2. 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.