ffcall on Darwin/PPC

Hello,

the recent change in gnustep-base and gnustep-startup to
check whether
ffcall trampolines work did remind me that I've been running
GNUstep
with ffcall instead of libffi on Darwin/PPC for quite a
while without
problems now. I've attached two small patches that make the
trampoline
test pass on Darwin/PPC, too (gcc on Darwin/PPC defines
__ppc__ or
__ppc64__ instead of __powerpc__), and make ffcall the
default on
Darwin/PPC as it is on other targets.

The main reason for this change is that libffi has a serious
problem
with message forwarding if the signatures of the forwarded
methods
are omitted. See this message:
http://lists.gnu.org/archive/html/discuss
-gnustep/2006-04/msg00107.html
and the ensuing short thread.

In fact, I had a little closer look at the issue and the
problem is
in function gs_objc_msg_forward in GSFFIInvocation.m. This
function
is invoked from the Objective-C runtime when a method
selector is not
implemented by the receiver of a method call. If the
compiler cannot
determine the signature of the called method, which happens
if the
receiver's class does not declare the method,
gs_objc_msg_forward uses
the fixed signature of a method with no arguments and an id
result. The
signature is then used to copy the method arguments into a
malloc'ed
buffer. Obviously, no arguments are copied at all in this
case and
hence the target of the forwarded method call will be called
with
undefined arguments. I do not see how this could ever be
fixed, so I'm
inclined to think that GNUstep should drop libffi.

Regards
Wolfgang

P.S.: Just for the record, I'm using FSF Gnu C 4.1.1 and
ffcall 1.10.


  
_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustepgnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Le 07-03-17 à 14:36, Wolfgang Lux a écrit :

> Hello,
>
> the recent change in gnustep-base and gnustep-startup
to check whether
> ffcall trampolines work did remind me that I've been
running GNUstep
> with ffcall instead of libffi on Darwin/PPC for quite a
while without
> problems now. I've attached two small patches that make
the trampoline
> test pass on Darwin/PPC, too (gcc on Darwin/PPC defines
__ppc__ or
> __ppc64__ instead of __powerpc__), and make ffcall the
default on
> Darwin/PPC as it is on other targets.
>
> The main reason for this change is that libffi has a
serious problem
> with message forwarding if the signatures of the
forwarded methods
> are omitted. See this message:
> http://lists.gnu.org/archive/html/discuss-gnustep/2006
-04/ 
> msg00107.html
> and the ensuing short thread.
>
> In fact, I had a little closer look at the issue and
the problem is
> in function gs_objc_msg_forward in GSFFIInvocation.m.
This function
> is invoked from the Objective-C runtime when a method
selector is not
> implemented by the receiver of a method call. If the
compiler cannot
> determine the signature of the called method, which
happens if the
> receiver's class does not declare the method,
gs_objc_msg_forward uses
> the fixed signature of a method with no arguments and
an id result.  
> The
> signature is then used to copy the method arguments
into a malloc'ed
> buffer. Obviously, no arguments are copied at all in
this case and
> hence the target of the forwarded method call will be
called with
> undefined arguments. I do not see how this could ever
be fixed, so I'm
> inclined to think that GNUstep should drop libffi.
>
> Regards
> Wolfgang
>
> P.S.: Just for the record, I'm using FSF Gnu C 4.1.1
and ffcall 1.10.

This is very interresting.  If no one has an argument
against this,  
I'll use it in MacPorts

yves



_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustepgnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Am 17.03.2007 um 19:36 schrieb Wolfgang Lux:

> In fact, I had a little closer look at the issue and
the problem is
> in function gs_objc_msg_forward in GSFFIInvocation.m.
This function
> is invoked from the Objective-C runtime when a method
selector is not
> implemented by the receiver of a method call. If the
compiler cannot
> determine the signature of the called method, which
happens if the
> receiver's class does not declare the method,
gs_objc_msg_forward uses
> the fixed signature of a method with no arguments and
an id result.  
> The
> signature is then used to copy the method arguments
into a malloc'ed
> buffer. Obviously, no arguments are copied at all in
this case and
> hence the target of the forwarded method call will be
called with
> undefined arguments. I do not see how this could ever
be fixed, so I'm
> inclined to think that GNUstep should drop libffi.

Did you file a bug with gcc on this?

http://gcc.gnu.org/bugzi
lla/

>
> Regards
> Wolfgang

regards, Lars



_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustepgnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

On Sat, Mar 17, 2007 at 07:36:47PM +0100, Wolfgang Lux
wrote:
> Obviously, no arguments are copied at all in this case
and hence the
> target of the forwarded method call will be called with
undefined
> arguments. I do not see how this could ever be fixed,
so I'm inclined
> to think that GNUstep should drop libffi.

Actually, I have submitted a patch to GCC to fix this
problem already,
and the fix is simply to provide the callback with both the
receiver and
the selector (why it was not done this way originally is
beyond me,
perhaps just an oversight).  From there, the intended
receiver can be
queried directly on the correct signature to use.  

http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00941.html

I do not think that libffi support should be dropped, as its
outlook for
the future is much brighter than ffcall, but I can certainly
say that
ALL of gnustep's invocation support (ffcall, libffi, and the
disabled
mframe) is at the moment quite broken when it comes to
retaining/releasing per apple documentation, and I know for
sure that
talksoup only works with ffcall, on ffi it destroys the
stack and
crashes who knows where right when I start running all the
invocation
code.

- Andy

-- 
Andrew Ruder <andyaeruder.net>
http://www.aeruder.net


_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustepgnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

On 3/17/07, Wolfgang Lux <wolfgang.luxgmail.com> wrote:
> I do not see how this could ever be fixed, so I'm
> inclined to think that GNUstep should drop libffi.

You know I have not see any bug reports from you about
libffi.  In
fact I rather have GNUStep always use libffi because it is
more
supported with more targets (and the semi official base code
is inside
GCC).  I am about to review the patch which used libffi
instead of
__builtin_apply (etc.) inside libobjc also.

Thanks,
Andrew Pinski
A GCC developer and the GNU libobjc maintainer


_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustepgnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Le 07-03-18 à 05:57, David Ayers a écrit :

> Andrew Pinski schrieb:
>> On 3/17/07, Wolfgang Lux <wolfgang.luxgmail.com> wrote:
>>
>>> I do not see how this could ever be fixed, so
I'm
>>> inclined to think that GNUstep should drop
libffi.
>>
>>
>> You know I have not see any bug reports from you
about libffi.  In
>> fact I rather have GNUStep always use libffi
because it is more
>> supported with more targets (and the semi official
base code is  
>> inside
>> GCC).  I am about to review the patch which used
libffi instead of
>> __builtin_apply (etc.) inside libobjc also.
>>
>
> I tend to agree with Andrew.  I have tried to contact
ffcall  
> maintainers
> for issues in either SPARC or NetBSD architectures and
haven't had
> productive responses.
>
> IIRC, building the development environment for ffcall
entails
> non-portable configure scripts and specific gcc
versions (2.7.?).
>
> The problem is that both libffi and ffcall solve
non-trivial problems
> and /I/ haven't been able to easily find the
documentation needed to
> use/fix them...  which makes formulating useful bug
reports also
> non-trivial.
>
> But realize that libffi is what gcc's java
implementation uses so for
> the common platforms I believe the issues don't
necessarily lay within
> libffi.

BTW, it seems the only way to build libffi with gcc is to
build java  
(just objc won't do).

I can't really follow the discussion, but my need to
oversimplify  
things leads me to the following conclusions :

1- ffcall works better than ffi today
2- ffi has a brighter tomorrow
3- libobjc would be better by its own (after tomorrow)

not too far off ?

thanks

yves



_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustepgnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Yves de Champlain schrieb:
> 
> Le 07-03-18 à 05:57, David Ayers a écrit :
> 
> 
> BTW, it seems the only way to build libffi with gcc is
to build java 
> (just objc won't do).

Hmm... that's related to a patch I dropped...  I wanted to
submit a
patch to have libffi build as a target library  after I
submitted the
patch to have boehm-gc be build with libobjc with garbage
collection
without having to build java.

But then I had decided that making libffi a target library
is not really
the final solution.  The solution would be to implement
message
forwarding in libobjc proper.

But I still think that you should be able to build libffi
stand alone...
at least you used to be able to...

/me updates gcc tree
/me creates a build directory
/me invokes '../trunk/libffi/configure'
/me invokes 'make' (not make bootstrap!)

and libffi builds... now 'make check' indeed fails as I
believe it does
require building the full gcc tree.  Also I did not install
it.  But
what issues did you have building libffi without gcc?

> I can't really follow the discussion, but my need to
oversimplify 
> things leads me to the following conclusions :
> 
> 1- ffcall works better than ffi today

I would not say that ffcall works better than ffi today.  I
would say
that it may work better on some platforms and potentially
only with
certain versions of gcc.  Yet you could inverse that
statement with
other platform/gcc combinations.

IOW, YMMV and I don't think it makes sense to prefer one
over the other
in a general statement currently.  Instead we should rather
collect the
"information" which combinations /don't/ work. 
Now whether that
"information" is collected:
- statically and potentially documented in the prerequisites
or
- dynamically by our configure scripts that simply report
failures,
is something I don't feel strongly about.

It's just important to me that we don't suggest that one is
generally
"better" at this stage because that's simply not
true.

> 2- ffi has a brighter tomorrow

Agreed.

> 3- libobjc would be better by its own (after tomorrow)

I'd try to be more precise by saying that message forwarding
would
better be implemented in future versions of libobjc, but
yes... that's a
task for tomorrow... I wouldn't say 'after' tomorrow since
ffi support
is in gcc today, but yes it's something that someone would
still have to
do.  And potentially a SoC project for gcc?

Cheers,
David


_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustepgnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Le 07-03-18 à 12:11, David Ayers a écrit :

> Yves de Champlain schrieb:
>>
>> Le 07-03-18 à 05:57, David Ayers a écrit :
>>
>>
>> BTW, it seems the only way to build libffi with gcc
is to build java
>> (just objc won't do).
>
> Hmm... that's related to a patch I dropped...  I wanted
to submit a
> patch to have libffi build as a target library  after I
submitted the
> patch to have boehm-gc be build with libobjc with
garbage collection
> without having to build java.
>
> But then I had decided that making libffi a target
library is not  
> really
> the final solution.  The solution would be to implement
message
> forwarding in libobjc proper.
>
> But I still think that you should be able to build
libffi stand  
> alone...
> at least you used to be able to...
>
> /me updates gcc tree
> /me creates a build directory
> /me invokes '../trunk/libffi/configure'
> /me invokes 'make' (not make bootstrap!)
>
> and libffi builds... now 'make check' indeed fails as I
believe it  
> does
> require building the full gcc tree.  Also I did not
install it.  But
> what issues did you have building libffi without gcc?

My issue was trying to have libffi built along with gcc
without  
building gcj (which is sooooo long to compile).  It's not so
 
important now because I happened to also need gcj since then
   
It's just that I thought --enable-languages=objc should
trigger  
libffi even though java is not built.

Thanks for all the precisions.

yves



_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustepgnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Yves de Champlain schrieb:
> 
> 
> My issue was trying to have libffi built along with gcc
without 
> building gcj (which is sooooo long to compile).  It's
not so  important
> now because I happened to also need gcj since then    It's
just that
> I thought --enable-languages=objc should trigger 
libffi even though
> java is not built.
> 

Well technically libobjc doesn't depend on libffi (yet) so
it isn't
built as resource for libobjc as it is for java.  And
because it isn't
considered a full fledged target library, you cannot enable
it
explicitly during a gcc build.  Yet since you can build it
separately,
there is hardly any motivation to make it a full fledged
target library.

Now if libobjc started to implement method forwarding with
libffi, then
libffi will be build with libobjc just as it is currently
build for java
as you were expecting.

[I'm just being this explicit for the archives].

Cheers,
David


_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustepgnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Hi

2 questions about base.patch

why the gdomap port override ?

I have no config/config.trampoline.c in my 1.13.1 base
source.

yves



_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustepgnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep