This mail is an automated notification from the bugs tracker
of the project: GNUstep.
/**************************************************************************/
[bugs #9382] Latest Modifications:
Changes by:
David Ayers <[EMAIL PROTECTED]>
'Date:
Fri 07/30/2004 at 17:32 (Europe/Vienna)
------------------ Additional Follow-up Comments ----------------------------
It seems that this patch will cause problems when communicating to GNUstep processes
that haven't been updated. I'm uncertain whether this can be resolved.
The issue again: GCC encodes the signature in a "relatively" platform indepenent
way.It seems that this patch will cause problems when communicating to GNUstep
processes that haven't been updated. I'm uncertain whether this can be resolved.
The issue again: GCC encodes the signature in a "relatively" platform independent
way. I say "relatively" as it does mark arguments that it assumes are passed in
registers with '+'. Yet it also assumes that every signature has [EMAIL PROTECTED]:*
(see gcc/gcc/objc/objc-act.c). Yet the mframe code knows better. On some systems
(like Solaris this produces warnings like:
2004-07-30 15:33:54.000 nsnotification[22083] File GSFFCallInvocation.m: 856.
In GSInvocationCallback Changed type signature
'[EMAIL PROTECTED]:[EMAIL PROTECTED]@[EMAIL PROTECTED]@24' to
'[EMAIL PROTECTED]:[EMAIL PROTECTED]@[EMAIL PROTECTED]@+28' for
'postNotificationName:object:userInfo:deliverImmediately:for:'
On other platforms (hppa) the the mframe code produces signatures with '-' to
signalize parameters on the stack. Those would get registered with the runtime yet
libobjc does not recognize those characters and once these signatures get registered,
will abort.
So this is why I meant to differentiate between the libobjc/GCC signatures used within
the process and the mframe signatures used for the FFI/FFCall code. Yet this seem to
break callframe.m's assertion in
callframe_do_call():
NSCParameterAssert (sel_types_match(encoded_types, type));
on some platforms when DO is used with unpatched versions. I personally can't
reproduce this but maybe Richard can help out on this.
/**************************************************************************/
[bugs #9382] Full Item Snapshot:
URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=9382>
Project: GNUstep
Submitted by: David Ayers
On: Fri 06/18/2004 at 17:08
Category: Base/Foundation
Severity: 5 - Average
Item Group: Bug
Resolution: None
Assigned to: ayers
Status: Open
Summary: mframe vs. gcc/libobjc selector types
Original Submission: We use the platform dependent mframe code to implement
NSMethodSignature's method types while gcc/libobjc uses a platform independent
encoding scheme (well in pre 3.4 version it wasn't fully platform independent as it
marked where registers were used depending on the platform but the "ObjC improvements"
merge broke that.) Unfortunately we use these mframe signatures to register selectors
for DO (see Testing/nsnotification). Yet the mframe encoding "dialects" cannot be
handled by libobjc which causes objc_error aborts on some platforms (e.g. linux/hppa
but potentially others) when selectors are registered with those types. I believe we
need to reorganize NSMethodSignature to use the "gcc/libobjc" encoding dialect instead
of the mframe dialects which should be resrced for DO processing. I haven't looked
into how this could be done yet. Maybe someone a bit more familiar with this code may
want to jump in and have a look at it. Riccardo
Mottola can provide information (if I'm not available) and test. Otherwise I'll drop
it on my TODO list.
Follow-up Comments
------------------
-------------------------------------------------------
Date: Fri 07/30/2004 at 17:32 By: ayers
It seems that this patch will cause problems when communicating to GNUstep processes
that haven't been updated. I'm uncertain whether this can be resolved.
The issue again: GCC encodes the signature in a "relatively" platform indepenent
way.It seems that this patch will cause problems when communicating to GNUstep
processes that haven't been updated. I'm uncertain whether this can be resolved.
The issue again: GCC encodes the signature in a "relatively" platform independent
way. I say "relatively" as it does mark arguments that it assumes are passed in
registers with '+'. Yet it also assumes that every signature has [EMAIL PROTECTED]:*
(see gcc/gcc/objc/objc-act.c). Yet the mframe code knows better. On some systems
(like Solaris this produces warnings like:
2004-07-30 15:33:54.000 nsnotification[22083] File GSFFCallInvocation.m: 856.
In GSInvocationCallback Changed type signature
'[EMAIL PROTECTED]:[EMAIL PROTECTED]@[EMAIL PROTECTED]@24' to
'[EMAIL PROTECTED]:[EMAIL PROTECTED]@[EMAIL PROTECTED]@+28' for
'postNotificationName:object:userInfo:deliverImmediately:for:'
On other platforms (hppa) the the mframe code produces signatures with '-' to
signalize parameters on the stack. Those would get registered with the runtime yet
libobjc does not recognize those characters and once these signatures get registered,
will abort.
So this is why I meant to differentiate between the libobjc/GCC signatures used within
the process and the mframe signatures used for the FFI/FFCall code. Yet this seem to
break callframe.m's assertion in
callframe_do_call():
NSCParameterAssert (sel_types_match(encoded_types, type));
on some platforms when DO is used with unpatched versions. I personally can't
reproduce this but maybe Richard can help out on this.
-------------------------------------------------------
Date: Fri 07/02/2004 at 08:20 By: ayers
Patch reverted due to problems on other platforms.
-------------------------------------------------------
Date: Thu 07/01/2004 at 11:42 By: ayers
Patch commited.
-------------------------------------------------------
Date: Sat 06/19/2004 at 19:00 By: ayers
I've attached a patch that fixes the problem. There still may be some underlaying
cleanup needed. (Check why the GSInvocationCallback functions get a selector with
platform specific types and fix that). But I'll leave that for later (or someone else
to pickup) because I'm out of time now. It would be nice if those of you who use DO
intensively (maybe even cross platform DO) could take it for a spin.
File Attachments
-------------------
-------------------------------------------------------
Date: Fri 07/30/2004 at 17:32 Name: base.patch Size: 5.69KB By: ayers
NSMethodSignature/GSInvocationCallback patch
http://savannah.gnu.org/bugs/download.php?item_id=9382&item_file_id=1544
For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=9382>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-gnustep mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-gnustep
