[PATCH] Fix libffi on m68k-linux-gnu, completely

[Thorsten Glaser <tg at mirbsd dot de>]

Note: Doko and Andreas, youâre mentioned further below.


Andreas Schwab dixit:

>Alan Hourihane <alanh@fairlite.co.uk> writes:
>
>> Fixed the test, as it was broken.
>
>No, it isn't.

Hi you two, Iâve seen you fixed all failures than the (above discussed)
return_sc. I took care of that one today. (If I get my hands on the
person responsible for the lsr.l codepath, when the other routine uses
something so much easier to spot, thus being so temptingly easy, making
me not look harderâ this cost me quite some time today!)

Hello libffi developers upstream, please do apply the attached patch
against git master, and then mark m68k-linux-gnu as working/tested
platform. Iâm getting a full testsuite pass for both 3.0.10 with the
m68k code updated, and no new failures for 3.0.11 with the patch applied
although I believe some 3.0.11 checks to be broken:

The cls_uchar.c test has:

static void cls_ret_uchar_fn(ffi_cif* cif __UNUSED__, void* resp,
    void** args, void* userdata __UNUSED__) {
	*(ffi_arg*)resp = *(unsigned char *)args[0];

The cls_uchar_va.c test has (T expanded):

static void cls_ret_T_fn(ffi_cif* cif __UNUSED__, void* resp,
    void** args, void* userdata __UNUSED__) {
	*(unsigned char *)resp = *(unsigned char *)args[0];

Now, on big endian platforms, the result is quite different:

Assuming we call them with args[0]=0x7F, then:
Before: *(unsigned long *)resp = { 0x??, 0x??, 0x??, 0x?? }
After1: *(unsigned long *)resp = { 0x00, 0x00, 0x00, 0x7F }
After2: *(unsigned long *)resp = { 0x7F, 0x??, 0x??, 0x?? }

The failing tests are contributed by ARM, who are using
Little Endian, or so Iâm told, so itâs no surprise they
didnât notice. Whatâs the correct method to access *resp
in a closure, casting to the ârealâ return type or to an
ffi_arg pointer (the latter is used by all other/older
tests, i.e. all those predating arm64 support).

The failing tests (both before and after my patch) are:
libffi.call/cls_uchar_va.c cls_ushort_va.c va_1.c
The following exemplary patch makes one of them pass:
--- cls_uchar_va.c      2012-12-02 21:34:19.000000000 +0000
+++ cls_uchar_va2.c     2012-12-02 22:26:37.000000000 +0000
@@ -12,9 +12,9 @@
 static void cls_ret_T_fn(ffi_cif* cif __UNUSED__, void* resp, void** args,
                         void* userdata __UNUSED__)
  {
-   *(T *)resp = *(T *)args[0];
+   *(ffi_arg *)resp = *(T *)args[0];
 
-   printf("%d: %d %d\n", *(T *)resp, *(T *)args[0], *(T *)args[1]);
+   printf("%d: %d %d\n", (int)(*(ffi_arg *)resp), *(T *)args[0], *(T *)args[1]);
  }
 
 typedef T (*cls_ret_T)(T, ...);


And, WTF: Why is there a .pc directory in the git repository?


Hello Debian libffi maintainer, you will receive patches in a separate
message against unstable (3.0.10) and experimental (3.0.11) as well as
gcc-4.7 (uses something close to 3.0.10 but not quite).

Andreas, I think you can commit the GCC side of the patch as well, so
Iâll keep debian-68k on Cc for the followup message with them.

bye,
//mirabilos
-- 
Darwinism never[â]applied to wizardkind. There's a more than fair amount of[â]
stupidity in its gene-pool[â]never eradicated[â]magic evens the odds that way.
It's[â]harder to die for us than[â]muggles[â]wonder if, as technology[â]better
[â]same will[â]happen there too. Dursleys' continued existence indicates so.

Attachment: 0001-Fix-8-bit-and-16-bit-signed-calls-on-m68k.patch
Description: Text document