bugGNUstep - Bugs: bug #9382, mframe vs. gcc/libobjc selector...

 
 

bug #9382: mframe vs. gcc/libobjc selector types

Submitted by:  David Ayers <ayers>
Submitted on:  Fri 18 Jun 2004 05:08:00 PM UTC  
 
Category:  Base/Foundation Severity:  3 - Normal
Item Group:  Bug Status:  Wont Fix
Privacy:  Public Assigned to:  None
Open/Closed:  Declined

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Thu 11 Jun 2009 03:10:15 PM UTC, comment #8: 

Actually I do not know whether it is still valid.
But given the fact that
- I lack the time to look it
- we are moving toward libffi and any new development should be done there
- noone has time/interest to readd that information to gcc generated signature
- I'm not sure it's strictly necessary for gcc to provide it

I think it's fair to mark this WONT FIX and move towards obsoleting mframe code.

David Ayers <ayers>
Project Member
Thu 11 Jun 2009 10:59:55 AM UTC, comment #7: 

David, this bug has been arond for ages... is it still valid?

Riccardo Mottola <rmottola>
Project Member
Sat 04 Sep 2004 05:57:50 AM UTC, comment #6: 

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.

David Ayers <ayers>
Project Member
Sun 01 Aug 2004 04:00:41 AM UTC, comment #5: 

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)?

Anonymous
Fri 30 Jul 2004 05:32:04 PM UTC, comment #4: 

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.

David Ayers <ayers>
Project Member
Fri 02 Jul 2004 08:20:07 AM UTC, comment #3: 

Patch reverted due to problems on other platforms.

David Ayers <ayers>
Project Member
Thu 01 Jul 2004 11:42:08 AM UTC, comment #2: 

Patch commited.

David Ayers <ayers>
Project Member
Sat 19 Jun 2004 07:00:58 PM UTC, comment #1: 

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.

David Ayers <ayers>
Project Member
Fri 18 Jun 2004 05:08:00 PM UTC, 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.

David Ayers <ayers>
Project Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #1425:  base.patch added by ayers (6KiB - application/octet-stream - NSMethodSignature/GSInvocationCallback patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ayers (Posted a comment)
  • -email is unavailable- added by rmottola (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 13 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-06-11 ayers StatusRemind => Wont Fix
        Assigned toayers => None
        Open/ClosedOpen => Declined
    2004-09-04 ayers StatusNone => Remind
    2004-07-30 ayers Attached File- => Added base.patch, #1544
    2004-07-30 ayers Attached File#1417 => Removed
    2004-07-02 ayers StatusFixed => None
        Open/ClosedClosed => Open
    2004-07-01 ayers StatusNone => Fixed
        Open/ClosedIn Test => Closed
    2004-06-19 ayers Assigned toNone => ayers
        Open/ClosedOpen => In Test
        Attached File- => Added base.patch, #1417

    Back to the top


    Powered by Savane 3.6