[bugs #9382] mframe vs. gcc/libobjc selector types

[David Ayers]

This mail is an automated notification from the bugs tracker
 of the project: GNUstep.

/**************************************************************************/
[bugs #9382] Latest Modifications:

Changes by: 
                David Ayers <d.ayers@inode.at>
'Date: 
                Sat 09/04/2004 at 05:57 (Europe/Vienna)

            What     | Removed                   | Added
---------------------------------------------------------------------------
          Resolution | None                      | Remind


------------------ Additional Follow-up Comments ----------------------------
This is actually a gcc/libobjc issue.  Before 3.4 gcc used to emit layout 
information in the selector type, presumably to help our obsolete mframe code 
figure out the layout for builtin_apply.  As we require ffcall/ffi and do not 
rely on this layout information, we currently work fine with gcc 3.4 in this 
respect.

On some systems where the stack grows backwards gcc emitted offsets with 
negative values.  Yet no libobjc version actually supports these negative 
offsets (see objc_sel_types_match, objc_skip_offset and a few others that use 
these functions).  We've hacked around this in -base by reimplementing 
GSSelectorTypesMatch and either skipping the '-' character manually or only 
using those functions on type signatures generated by our own mframe code which 
doesn't produce these negative offsets.

I'll leave this report open as reminder to test platforms like 
hppa-unkown-gnu-linux before reworking the mframe code after the release.







/**************************************************************************/
[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:  Remind
Privacy:  Public
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: Sat 09/04/2004 at 05:57       By: David Ayers <ayers>
This is actually a gcc/libobjc issue.  Before 3.4 gcc used to emit layout 
information in the selector type, presumably to help our obsolete mframe code 
figure out the layout for builtin_apply.  As we require ffcall/ffi and do not 
rely on this layout information, we currently work fine with gcc 3.4 in this 
respect.

On some systems where the stack grows backwards gcc emitted offsets with 
negative values.  Yet no libobjc version actually supports these negative 
offsets (see objc_sel_types_match, objc_skip_offset and a few others that use 
these functions).  We've hacked around this in -base by reimplementing 
GSSelectorTypesMatch and either skipping the '-' character manually or only 
using those functions on type signatures generated by our own mframe code which 
doesn't produce these negative offsets.

I'll leave this report open as reminder to test platforms like 
hppa-unkown-gnu-linux before reworking the mframe code after the release.


-------------------------------------------------------
Date: Sun 08/01/2004 at 04:00       By: 0 <None>
I wonder if there is anyway to determine dynamically if a patched version is 
talking to an unpatched version, and have the patched version 'revert' back to 
using the old way (probably controlled at compile time by a flag for users that 
need this capability)?

-------------------------------------------------------
Date: Fri 07/30/2004 at 17:32       By: David Ayers <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 
*@0:* (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 
'Vv28@0:4@8@12@16C20@24' to 
'Vv0@+8:+12@+16@+20@+24C+25@+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: David Ayers <ayers>
Patch reverted due to problems on other platforms.

-------------------------------------------------------
Date: Thu 07/01/2004 at 11:42       By: David Ayers <ayers>
Patch commited.

-------------------------------------------------------
Date: Sat 06/19/2004 at 19:00       By: David Ayers <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&amp;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/