[issue7201] double Endian problem and more on arm

[Meador Inge]

Meador Inge <meadori at gmail.com> added the comment:

OK, I got an OABI system setup.  I am seeing the 'test_struct_return_2H' 
failure, which actually segfaults in my setup.  The difference does, 
indeed, seem like an ABI mismatch.

The test code that is failing has a Python side like:

   def test_struct_return_2H(self):
        class S2H(Structure):
            _fields_ = [("x", c_short),
                        ("y", c_short)]
        dll.ret_2h_func.restype = S2H
        dll.ret_2h_func.argtypes = [S2H]
        inp = S2H(99, 88)
        s2h = dll.ret_2h_func(inp)
        self.assertEqual((s2h.x, s2h.y), (99*2, 88*3))

and a C code side that looks like:

   typedef struct {
      short x;
      short y;
   } S2H;

   S2H ret_2h_func(S2H inp)
   {
      inp.x *= 2;
      inp.y *= 3;
      return inp;
   }

The APCS Section 5.4 Result Return [1], says:

"""
A Composite Type not larger than 4 bytes is returned in r0.  The format 
is as if the result had been stored in memory at a word-aligned address 
and then loaded into r0 with an LDR instruction.  Any bits in r0 that 
lie outside the bounds of the result have unspecified values.
"""

The EABI implementation does exactly this and packs the structure into r0, where as the OABI implementation places the address of a structure in r0.  'ctypes' is assuming the former and on an OABI system the contents of r0 are treated as an address, where they are actually a value.  Boom goes the dynamite.

I am looking into 'test_endian_double' and 
'test_unaligned_native_struct_fields' now.

[1] http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042d/IHI0042D_aapcs.pdf

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7201>
_______________________________________