* Libffi problem on darwin (MacOSX)
@ 2003-05-16 20:56 Ronald Oussoren
2003-05-16 21:42 ` Dale Johannesen
0 siblings, 1 reply; 8+ messages in thread
From: Ronald Oussoren @ 2003-05-16 20:56 UTC (permalink / raw)
To: gcc
Hi,
The libffi mailing seems to be dead, hence my post here. I'm using
libffi to interface Python and Objective-C (http://pyobjc.sf.net). This
is working pretty well, but I'm running into a problem that seems to be
libffi related.
We're using libffi closures in the Objective-C method tables to forward
calls from Objective-C to python. This is working fine for basic calls,
but gives wrong results when structs are passed. It looks like a
mismatch between the compiler and libffi: ffi_closure_helper_DARWIN in
libffi_darwin.c seems to assume that structs are passed "by reference"
(line 615), while the compiler passes small structs entirely in
registers (see assembly code emited by the following C snippet):
struct foobar {
float a;
int b;
};
extern struct foobar h;
extern int i;
void callee(struct foobar a1, int a2)
{
}
void caller(void)
{
struct foobar g = { 1.0, 2.0 };
callee(g, 42);
}
The compiler behaviour seems to be the same as prescribed by 'Mach-O
runtime conventions on PowerPC'
(http://developer.apple.com/techpubs/macosx/DeveloperTools/
MachORuntime/2rt_powerpc_abi/index.html).
I'm using Apple's version of GCC 3.1 and a libffi from the GCC
repository (HEAD branch). I've disabled the eh_frames in darwin*.S
(otherwise this version of libffi won't work with Apple's GCC), but
otherwise it's the same as in CVS.
Ronald
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Libffi problem on darwin (MacOSX)
2003-05-16 20:56 Libffi problem on darwin (MacOSX) Ronald Oussoren
@ 2003-05-16 21:42 ` Dale Johannesen
2003-05-17 6:03 ` Andreas Tobler
0 siblings, 1 reply; 8+ messages in thread
From: Dale Johannesen @ 2003-05-16 21:42 UTC (permalink / raw)
To: Ronald Oussoren; +Cc: Dale Johannesen, gcc
On Friday, May 16, 2003, at 01:55 PM, Ronald Oussoren wrote:
> We're using libffi closures in the Objective-C method tables to
> forward calls from Objective-C to python. This is working fine for
> basic calls, but gives wrong results when structs are passed. It looks
> like a mismatch between the compiler and libffi:
> ffi_closure_helper_DARWIN in libffi_darwin.c seems to assume that
> structs are passed "by reference" (line 615), while the compiler
> passes small structs entirely in registers (see assembly code emited
> by the following C snippet):
I'm not familiar with libffi, but I can confirm that the compiler is
doing the
right thing, and it's the same thing it's always done. It looks like
ffi_prep_args
and ffi_prep_cif_machdep correctly understand that structs are passed
by value, so
this is just a bug in ffi_closure_helper_DARWIN.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Libffi problem on darwin (MacOSX)
2003-05-16 21:42 ` Dale Johannesen
@ 2003-05-17 6:03 ` Andreas Tobler
2003-05-17 10:17 ` Ronald Oussoren
0 siblings, 1 reply; 8+ messages in thread
From: Andreas Tobler @ 2003-05-17 6:03 UTC (permalink / raw)
To: Dale Johannesen; +Cc: Ronald Oussoren, gcc
Dale Johannesen wrote:
> On Friday, May 16, 2003, at 01:55 PM, Ronald Oussoren wrote:
>
>> We're using libffi closures in the Objective-C method tables to
>> forward calls from Objective-C to python. This is working fine for
>> basic calls, but gives wrong results when structs are passed. It looks
>> like a mismatch between the compiler and libffi:
>> ffi_closure_helper_DARWIN in libffi_darwin.c seems to assume that
>> structs are passed "by reference" (line 615), while the compiler
>> passes small structs entirely in registers (see assembly code emited
>> by the following C snippet):
>
>
> I'm not familiar with libffi, but I can confirm that the compiler is
> doing the
> right thing, and it's the same thing it's always done. It looks like
> ffi_prep_args
> and ffi_prep_cif_machdep correctly understand that structs are passed by
> value, so
> this is just a bug in ffi_closure_helper_DARWIN.
Hey great, people are using libffi on darwin-ppc. I guess this is born
on my camp. I'll have a look at, as soon as time allows here.
It is possible that I didn't finish the libffi regarding structures
since I didn't need it for libjava work. So, you could be right.
Thank you for the report.
Andreas
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Libffi problem on darwin (MacOSX)
2003-05-17 6:03 ` Andreas Tobler
@ 2003-05-17 10:17 ` Ronald Oussoren
2003-05-17 15:39 ` Andreas Tobler
0 siblings, 1 reply; 8+ messages in thread
From: Ronald Oussoren @ 2003-05-17 10:17 UTC (permalink / raw)
To: Andreas Tobler; +Cc: Dale Johannesen, gcc
On Saturday, May 17, 2003, at 07:52 Europe/Amsterdam, Andreas Tobler
wrote:
> Dale Johannesen wrote:
>> On Friday, May 16, 2003, at 01:55 PM, Ronald Oussoren wrote:
>>> We're using libffi closures in the Objective-C method tables to
>>> forward calls from Objective-C to python. This is working fine for
>>> basic calls, but gives wrong results when structs are passed. It
>>> looks like a mismatch between the compiler and libffi:
>>> ffi_closure_helper_DARWIN in libffi_darwin.c seems to assume that
>>> structs are passed "by reference" (line 615), while the compiler
>>> passes small structs entirely in registers (see assembly code emited
>>> by the following C snippet):
>> I'm not familiar with libffi, but I can confirm that the compiler is
>> doing the
>> right thing, and it's the same thing it's always done. It looks like
>> ffi_prep_args
>> and ffi_prep_cif_machdep correctly understand that structs are passed
>> by value, so
>> this is just a bug in ffi_closure_helper_DARWIN.
>
> Hey great, people are using libffi on darwin-ppc.
And were very glad this is available on darwin-ppc, libffi is a very
usefull library.
> I guess this is born on my camp. I'll have a look at, as soon as time
> allows here.
> It is possible that I didn't finish the libffi regarding structures
> since I didn't need it for libjava work. So, you could be right.
I just noticed that this might well be stupidity on my part, I tried to
write a minimal program that demonstrates the problem and that runs
without problems. Our real code builds ffi_cifs and ffi_closures at
runtime, and maybe that code is bogus.
Sorry about the inconvenience,
Ronald
--- example.c ---
#include "ffi.h"
#include <stdio.h>
struct foobar {
float a;
int b;
};
void callee(struct foobar a1, int a2)
{
printf("%g@%d %d\n", a1.a, a1.b, a2);
}
void stub(ffi_cif* cif, void* resp, void** args, void* userdata)
{
struct foobar a1;
int a2;
a1 = *(struct foobar*)(args[0]);
a2 = *(int*)(args[1]);
callee(a1, a2);
}
int main(void)
{
ffi_type* foobar_fields[3];
ffi_type foobar_type;
ffi_cif cif;
ffi_closure cl;
ffi_status rv;
void* args[4];
ffi_type* arg_types[3];
struct foobar g = { 1.0, 2.0 };
int fourtytwo = 42;
foobar_type.size = 0;
foobar_type.alignment = 0;
foobar_type.type = FFI_TYPE_STRUCT;
foobar_type.elements = foobar_fields;
foobar_fields[0] = &ffi_type_float;
foobar_fields[1] = &ffi_type_sint;
foobar_fields[2] = NULL;
arg_types[0] = &foobar_type;
arg_types[1] = &ffi_type_sint;
arg_types[2] = NULL;
rv = ffi_prep_cif(&cif, FFI_DEFAULT_ABI, 2, &ffi_type_void, arg_types);
if (rv != FFI_OK) {
printf("ffi cif: %d\n", rv);
abort();
}
printf ("Direct call:");
callee(g, fourtytwo);
printf("FFI call:");
args[0] = &g;
args[1] = &fourtytwo;
args[2] = NULL;
ffi_call(&cif, FFI_FN(callee), NULL, args);
printf("FFI closure call:");
rv = ffi_prep_closure(&cl, &cif, stub, NULL);
if (rv != FFI_OK) {
printf("ffi cl: %d\n", rv);
abort();
}
((void(*)(struct foobar, int))(&cl))(g, fourtytwo);
return 0;
}
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Libffi problem on darwin (MacOSX)
2003-05-17 10:17 ` Ronald Oussoren
@ 2003-05-17 15:39 ` Andreas Tobler
2003-05-25 20:49 ` Ronald Oussoren
0 siblings, 1 reply; 8+ messages in thread
From: Andreas Tobler @ 2003-05-17 15:39 UTC (permalink / raw)
To: Ronald Oussoren; +Cc: Dale Johannesen, gcc
Ronald Oussoren wrote:
>
> On Saturday, May 17, 2003, at 07:52 Europe/Amsterdam, Andreas Tobler wrote:
Hm, Amsterdam? I live in Zürich.... :)
>> Hey great, people are using libffi on darwin-ppc.
>
> And were very glad this is available on darwin-ppc, libffi is a very
> usefull library.
Fine, let me know if you need some more functionality. I implemented the
closure stuff only for libjava. And I seem to be one of the only persons
using that. But hopefully soon I get the libjava on darwin that far that
everyone can use it.
>
>> I guess this is born on my camp. I'll have a look at, as soon as time
>> allows here.
>> It is possible that I didn't finish the libffi regarding structures
>> since I didn't need it for libjava work. So, you could be right.
>
>
> I just noticed that this might well be stupidity on my part, I tried to
> write a minimal program that demonstrates the problem and that runs
> without problems. Our real code builds ffi_cifs and ffi_closures at
> runtime, and maybe that code is bogus.
Could be, but if I remember right, I didn't complete the structure
passings. Maybe it works, but if not, then I certainly have to check
again. Well, I'll do that anyway.
>
> Sorry about the inconvenience,
no worry, you give me some kick to go over again :)
Thanks,
Andreas
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Libffi problem on darwin (MacOSX)
2003-05-17 15:39 ` Andreas Tobler
@ 2003-05-25 20:49 ` Ronald Oussoren
2003-05-26 5:24 ` Andreas Tobler
0 siblings, 1 reply; 8+ messages in thread
From: Ronald Oussoren @ 2003-05-25 20:49 UTC (permalink / raw)
To: Andreas Tobler; +Cc: Dale Johannesen, gcc
On Saturday, May 17, 2003, at 17:21 Europe/Amsterdam, Andreas Tobler
wrote:
>> I just noticed that this might well be stupidity on my part, I tried
>> to write a minimal program that demonstrates the problem and that
>> runs without problems. Our real code builds ffi_cifs and ffi_closures
>> at runtime, and maybe that code is bogus.
>
> Could be, but if I remember right, I didn't complete the structure
> passings. Maybe it works, but if not, then I certainly have to check
> again. Well, I'll do that anyway.
The following hack seems to work for the limited tests that I've done.
Note that this is *not* based on any understanding of the PPC calling
conventions, and therefore likely incorrect.
Ronald
***
/Volumes/Data/Users/ronald/Python-CVS/gcc/libffi/src/powerpc/
ffi_darwin.c Sat Feb 22 20:10:14 2003
--- ffi_darwin.c Sat May 24 22:02:44 2003
***************
*** 612,619 ****
--- 612,633 ----
case FFI_TYPE_SINT32:
case FFI_TYPE_UINT32:
case FFI_TYPE_POINTER:
+ // case FFI_TYPE_STRUCT:
+ /* there are 8 gpr registers used to pass values */
+ if (ng < 8) {
+ avalue[i] = pgr;
+ ng++;
+ pgr++;
+ } else {
+ avalue[i] = pst;
+ pst++;
+ }
+ break;
+
case FFI_TYPE_STRUCT:
/* there are 8 gpr registers used to pass values */
+ {
+ int left = (arg_types[i]->size);
if (ng < 8) {
avalue[i] = pgr;
ng++;
***************
*** 622,627 ****
--- 636,654 ----
avalue[i] = pst;
pst++;
}
+
+ /* Structs are in registers, skip values */
+ left -= sizeof(long);
+ while (left > 0) {
+ if (ng < 8) {
+ ng++;
+ pgr++;
+ } else {
+ pst++;
+ }
+ left -= sizeof(long);
+ }
+ }
break;
case FFI_TYPE_SINT64:
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Libffi problem on darwin (MacOSX)
2003-05-25 20:49 ` Ronald Oussoren
@ 2003-05-26 5:24 ` Andreas Tobler
2003-05-26 10:01 ` Ronald Oussoren
0 siblings, 1 reply; 8+ messages in thread
From: Andreas Tobler @ 2003-05-26 5:24 UTC (permalink / raw)
To: Ronald Oussoren; +Cc: Dale Johannesen, gcc
Ronald Oussoren wrote:
>
> On Saturday, May 17, 2003, at 17:21 Europe/Amsterdam, Andreas Tobler
> wrote:
>
>>> I just noticed that this might well be stupidity on my part, I tried
>>> to write a minimal program that demonstrates the problem and that
>>> runs without problems. Our real code builds ffi_cifs and
>>> ffi_closures at runtime, and maybe that code is bogus.
>>
>>
>> Could be, but if I remember right, I didn't complete the structure
>> passings. Maybe it works, but if not, then I certainly have to check
>> again. Well, I'll do that anyway.
>
>
> The following hack seems to work for the limited tests that I've done.
> Note that this is *not* based on any understanding of the PPC calling
> conventions, and therefore likely incorrect.
Thanks, I'll have a look at. It'll take a while since I will test
against libgcj which needs a longer time to build.
Do you have a dedicated testcase for?
Andreas
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Libffi problem on darwin (MacOSX)
2003-05-26 5:24 ` Andreas Tobler
@ 2003-05-26 10:01 ` Ronald Oussoren
0 siblings, 0 replies; 8+ messages in thread
From: Ronald Oussoren @ 2003-05-26 10:01 UTC (permalink / raw)
To: Andreas Tobler; +Cc: Dale Johannesen, gcc
On Monday, May 26, 2003, at 07:12 Europe/Amsterdam, Andreas Tobler
wrote:
> Ronald Oussoren wrote:
>> On Saturday, May 17, 2003, at 17:21 Europe/Amsterdam, Andreas Tobler
>> wrote:
>>>> I just noticed that this might well be stupidity on my part, I
>>>> tried to write a minimal program that demonstrates the problem and
>>>> that runs without problems. Our real code builds ffi_cifs and
>>>> ffi_closures at runtime, and maybe that code is bogus.
>>>
>>>
>>> Could be, but if I remember right, I didn't complete the structure
>>> passings. Maybe it works, but if not, then I certainly have to check
>>> again. Well, I'll do that anyway.
>> The following hack seems to work for the limited tests that I've
>> done. Note that this is *not* based on any understanding of the PPC
>> calling conventions, and therefore likely incorrect.
>
> Thanks, I'll have a look at. It'll take a while since I will test
> against libgcj which needs a longer time to build.
> Do you have a dedicated testcase for?
I don't have a small standalone testcase for this problem. The problem
is triggered by a unittest in PyObjC, I can use that to check patches.
Ronald
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2003-05-26 5:24 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-16 20:56 Libffi problem on darwin (MacOSX) Ronald Oussoren
2003-05-16 21:42 ` Dale Johannesen
2003-05-17 6:03 ` Andreas Tobler
2003-05-17 10:17 ` Ronald Oussoren
2003-05-17 15:39 ` Andreas Tobler
2003-05-25 20:49 ` Ronald Oussoren
2003-05-26 5:24 ` Andreas Tobler
2003-05-26 10:01 ` Ronald Oussoren
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).