Well alpha (little endian) also FTBFS so I guess this is not an endianess issue

FYI: http://wiki.debian.org/ArchitectureSpecificsMemo about the different debian ports

The logs don't really have any info; at minimum we'd need 
test_user_data/logs/stderr.log
from the build, but most likely that isn't useful either. It probably requires getting into a debugger on those architectures.

Created attachment 178486 [details]
Logs from ppc build

a Friend of mine try to build gjs on a ppc machine

Created attachment 178487 [details]
stderr.log

Created attachment 182167 [details] [review]
Byte-swap return value in gjs_invoke_c_function() on big endian machines

This patch fixes the problem on powerpc, but the root cause may be somewhere else.

Any new about this bug?

Any feedback about the proposed patch?

Thanks for the patch Michel!  It's not obvious to me why we would need to do this for return values, but not for e.g. arguments passed in.

Could this be a libffi issue?

It's definitely worth trying a quick libffi test program.   What version of libffi is in use here?  And where is it failing exactly?

I think that json-glib is failing with the same kind of error:

ERROR:gvariant-test.c:193:test_json_to_gvariant: assertion failed
(test_case->variant_data == variant_data): ("(byte 0xff,)" == "(byte 0x00,)")

gjs is failing with this:
JS LOG: Expected 255 (number) but was 0 (number)


See bug #650483

(In reply to comment #7)
> Thanks for the patch Michel!  It's not obvious to me why we would need to do
> this for return values, but not for e.g. arguments passed in.

I suspect there may be a mismatch about the size of the return value, which happens not to matter on little endian.

> Could this be a libffi issue?

It's possible. This is using libffi 3.0.9-7 from Debian.

(In reply to comment #10)
> (In reply to comment #7)
> > Thanks for the patch Michel!  It's not obvious to me why we would need to do
> > this for return values, but not for e.g. arguments passed in.
> 
> I suspect there may be a mismatch about the size of the return value, which
> happens not to matter on little endian.

So if you look at say:
https://github.com/atgreen/libffi/blob/master/testsuite/libffi.call/return_uc.c

What are we doing differently?

> > Could this be a libffi issue?
> 
> It's possible. This is using libffi 3.0.9-7 from Debian.

The powerpc build logs for libffi look fine:
https://buildd.debian.org/status/fetch.php?pkg=libffi&arch=powerpc&ver=3.0.10~rc8-5&stamp=1307830421

It would help a lot to narrow this down to exactly which C function it's trying to invoke and failing on.

First, I should note that I'm dragging my feet here because Michel's patch *feels* like a hack, and while it may end up being the best patch, I want to try harder to verify that.  But anyone wanting g-i on these architectures should feel free to ship and use the patch, as it's pretty safe.

Things that would help here:

1) A backtrace (run under gdb, when it crashes, call "t a a bt")
2) Double check that the libffi tests are in fact being run and used
3) Once we have a backtrace, look at how we're calling libffi.  Is it different from any of the libffi tests?

Hello,

I've done some libffi porting work on PowerPC, and I'm pretty sure that the bug here is in GNOME.  Specifically, the "return value" of the function seems to be always of type "GArgument", regardless of which &ffi_type_* value was passed into ffi_prep_cif() in girffi.c

Now, most architecture ABIs do not actually have "char" or "short" return types, or even argument types, as they will use an entire register (or an entire register-sized stack slot) to store arguments of those types.  So on a standard big-endian system with 32-bit integers (EG: PowerPC), you would expect an "unsigned char" to be represented by the low byte in the 32-bit "r3", with the upper 3 bytes having a value of zero.

With all that said, when *libffi* goes to store the result of the function call, it uses the &ffi_type_* to figure out what the size and memory alignment of the destination should be.  If the function returns a 32-bit integer in the return-value register, but you tell libffi that the return-value is an 8-bit "unsigned char", then it will store only the low 8 bits into the byte at the "return_value" pointer.

On a little-endian system, as long as the next 3 bytes are zeros, that won't matter, because the first byte is the low byte.  On the other hand, on a big-endian system, the first byte is the high byte.  So if somebody accesses the "GArgument return_value" as a uint32, they will get a completely bogus value.

I've read a fair bit of code that uses libffi, and quite frankly the glib wrappers around libffi are some of the most complicated that I have ever seen.  The glib code is at least as long as the entire PowerPC implementation of libffi, perhaps longer.  As far as I can tell it seems to be reimplementing some significant portions of the libffi interface "just to be different".

Cheers,
Kyle Moffett

-- 
Curious about my work on the Debian powerpcspe port?
I'm keeping a blog here: http://pureperl.blogspot.com/

This should probably be resolved as a duplicate of bug 665152. I verified that cherry-picking commits ca276a8281a045949fd3c2ad338260d808559a30 and dc69b12d5e44f9d3b209759082f721237a8c9a06 onto the gnome-3-2 branch fixes the tests and related problems in gnome-shell. Could there be a 1.30.2 release for this?

Sorry Michel for not looking at this earlier...it's difficult without having one of the machines on hand.  (But friendly reminder pings on patches are fine too)

*** This bug has been marked as a duplicate of bug 665152 ***