======================================================================
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

Can this be closed as "out of date"?

Starting from 3.7 Python always uses system libffi. 3.4 and 3.5 are in security bugfix only mode. So this issue is only for 2.7 and 3.6.