======================================================================
FAIL: test_ulonglong (ctypes.test.test_callbacks.Callbacks)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home2/buildbot/slave/trunk.loewis-sun/build/Lib/ctypes/test/test_callbacks.py", line 68, in test_ulonglong
    self.check_type(c_ulonglong, 42)
  File "/home2/buildbot/slave/trunk.loewis-sun/build/Lib/ctypes/test/test_callbacks.py", line 31, in check_type
    self.assertEqual(result, arg)
AssertionError: 0L != 42

The ubuntu and debian sparc buildbots show the same failure, none of the other buildbots do.

This bug is already reported here:
http://bugs.python.org/issue8142#msg101134

It's surprising that test_ulonglong fails, while test_longlong passes:  can the Linux Sparc ABI really be treating these two types differently?

Maybe more information could be gained by supplying a more interesting test value than 42---some 8-byte value with all bytes different, for example.

In any case, this seems likely to be a libffi bug somewhere;  maybe we could bring it up on the libffi mailing list.  If we can translate the failing Python code into failing C code first that would probably increase the chances of getting a good answer.  Without access to Sparc hardware, I don't see much other way of making progress here.

I have just studied the issue in detail; v8.S is indeed missing support for unsigned long long. Here is a patch.

Committed as r79892.

Martin, you should probably post your patch to upstream libffi.

It should be ported to py3k, the sparc buildbots still fail there.

> Committed as r79892.

Commited to py3k (r80106), but blocked in 3.1 (r80107) because Python 3.1 uses libffi 3.0.5.

I was going to say that I think that this issue can be closed now...

... but the src/sparc/v8.S file still looks wrong to me:  Martin fixed one missing FFI_TYPE_UINT64 case, but it looks to me as though there's another one, in ffi_call_v8.  The code starting at line 68 in that file looks like:

	cmp	%i3, FFI_TYPE_INT
	be,a	done
	st	%o0, [%i4]	! (delay)

	cmp	%i3, FFI_TYPE_FLOAT
	be,a	done
	st	%f0, [%i4+0]	! (delay)

	cmp	%i3, FFI_TYPE_DOUBLE
	be,a	double
	st	%f0, [%i4+0]	! (delay)

	cmp	%i3, FFI_TYPE_SINT8
	be,a	sint8
	sll	%o0, 24, %o0	! (delay)

	cmp	%i3, FFI_TYPE_UINT8
	be,a	uint8
	sll	%o0, 24, %o0	! (delay)

	cmp	%i3, FFI_TYPE_SINT16
	be,a	sint16
	sll	%o0, 16, %o0	! (delay)

	cmp	%i3, FFI_TYPE_UINT16
	be,a	uint16
	sll	%o0, 16, %o0	! (delay)

	cmp	%i3, FFI_TYPE_SINT64
	be,a	longlong
	st	%o0, [%i4+0]	! (delay)
done:
	ret
	restore

Shouldn't there should be another block here for FFI_TYPE_UINT64, essentially identical to the FFI_TYPE_SINT64 block?  Or am I missing something?

I don't know why this omission doesn't cause buildbot failures; perhaps it's because the compiled test function (e.g., tf_Q in _ctypes_test.c) just happens to already have placed the correct values in the right locations ([%i4 + 0] and [%i4 + 4]) already, before transferring them to o0 and o1.

I've asked about this on the libffi-discuss mailing list, as a follow-up to Victor's report there.

There seems to be also a problem with src/sparc/v9.S.
https://bugs.gentoo.org/show_bug.cgi?id=362065

FAIL: test_ulonglong (ctypes.test.test_callbacks.Callbacks)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/tmp/portage/dev-lang/python-2.7.2_pre20110403/work/python-2.7.2_pre20110403/Lib/ctypes/test/test_callbacks.py", line 72, in test_ulonglong
    self.check_type(c_ulonglong, 10955412242170339782)
  File "/var/tmp/portage/dev-lang/python-2.7.2_pre20110403/work/python-2.7.2_pre20110403/Lib/ctypes/test/test_callbacks.py", line 31, in check_type
    self.assertEqual(result, arg)
AssertionError: 10955412241121898851L != 10955412242170339782L