Thank you for your further analysis. It is quite interesting that I am getting different behaviour from you. This is the result with the libobjc that comes with gcc:

2012-07-06 14:34:25.200 perform[25646] First Test - Direct sending known method
2012-07-06 14:34:25.236 perform[25646] Foo methodSignatureForSelector called with wibble
2012-07-06 14:34:25.236 perform[25646] Returning sig <NSMethodSignature: 0x7ad938>
2012-07-06 14:34:25.236 perform[25646] Foo methodSignatureForSelector called with wibble
2012-07-06 14:34:25.236 perform[25646] Returning sig <NSMethodSignature: 0x85e768>
2012-07-06 14:34:25.237 perform[25646] Foo - received <GSFFIInvocation 0x7985d8 selector: wibble target: Foo> on <Foo: 0x63f1d8> meta 0
2012-07-06 14:34:25.237 perform[25646] Wibble

2012-07-06 14:34:25.237 perform[25646] Second Test - performSelector with known method
2012-07-06 14:34:25.237 perform[25646] Foo methodSignatureForSelector called with wibble
2012-07-06 14:34:25.237 perform[25646] Returning sig <NSMethodSignature: 0x76e998>
2012-07-06 14:34:25.237 perform[25646] Foo - received <GSFFIInvocation 0x799718 selector: wibble target: Foo> on <Foo: 0x63f1d8> meta 0
2012-07-06 14:34:25.237 perform[25646] Wibble

2012-07-06 14:34:25.237 perform[25646] Third Test - performSelector with unknown method
/home/fred/GNUstep/Examples/decimal/perform.app/perform: Uncaught exception NSInvalidArgumentException, reason: -[nil blah]: unrecognized selector sent to instance (null)

And ater commenting out the third test I get:

2012-07-06 14:42:03.737 perform[26679] First Test - Direct sending known method
2012-07-06 14:42:03.739 perform[26679] Foo methodSignatureForSelector called with wibble
2012-07-06 14:42:03.739 perform[26679] Returning sig <NSMethodSignature: 0x7ad938>
2012-07-06 14:42:03.739 perform[26679] Foo methodSignatureForSelector called with wibble
2012-07-06 14:42:03.739 perform[26679] Returning sig <NSMethodSignature: 0x85e768>
2012-07-06 14:42:03.739 perform[26679] Foo - received <GSFFIInvocation 0x7985d8 selector: wibble target: Foo> on <Foo: 0x63f1d8> meta 0
2012-07-06 14:42:03.739 perform[26679] Wibble

2012-07-06 14:42:03.739 perform[26679] Second Test - performSelector with known method
2012-07-06 14:42:03.740 perform[26679] Foo methodSignatureForSelector called with wibble
2012-07-06 14:42:03.740 perform[26679] Returning sig <NSMethodSignature: 0x76e998>
2012-07-06 14:42:03.740 perform[26679] Foo - received <GSFFIInvocation 0x799718 selector: wibble target: Foo> on <Foo: 0x63f1d8> meta 0
2012-07-06 14:42:03.740 perform[26679] Wibble

2012-07-06 14:42:03.740 perform[26679] Fourth Test - Direct sending unknown method
2012-07-06 14:42:03.740 perform[26679] Foo methodSignatureForSelector called with blah
2012-07-06 14:42:03.740 perform[26679] Returning sig <NSMethodSignature: 0x772d38>
2012-07-06 14:42:03.740 perform[26679] Foo methodSignatureForSelector called with blah
2012-07-06 14:42:03.740 perform[26679] Returning sig <NSMethodSignature: 0x766608>
2012-07-06 14:42:03.740 perform[26679] Foo - received <GSFFIInvocation 0x7a7ee8 selector: blah target: Foo> on <Foo: 0x63f1d8> meta 0
2012-07-06 14:42:03.740 perform[26679] Redirecting unknown method blah
2012-07-06 14:42:03.740 perform[26679] Wibble

2012-07-06 14:42:03.740 perform[26679] Fifth Test - performSelector with unknown method, after directly sending it
2012-07-06 14:42:03.740 perform[26679] Foo methodSignatureForSelector called with blah
2012-07-06 14:42:03.740 perform[26679] Returning sig <NSMethodSignature: 0x83d478>
2012-07-06 14:42:03.740 perform[26679] Foo - received <GSFFIInvocation 0x83de28 selector: blah target: Foo> on <Foo: 0x63f1d8> meta 0
2012-07-06 14:42:03.740 perform[26679] Redirecting unknown method blah
2012-07-06 14:42:03.740 perform[26679] Wibble


I hope that David and Nicola will be joining us for further discussion.

Looks like my analysis was wrong. David Chisnell send me a short program that shows that the forwarding mechanism is working well for the different libobjc implementation. Here a slightly extended version of his code:

#import <Foundation/Foundation.h>

@interface Foo : NSObject @end
@implementation Foo
- (void)forwardInvocation: (NSInvocation*)inv
{
  NSLog(@"Received %@ on %@ meta %d", inv,
        self, class_isMetaClass(object_getClass(self)));
}
@end
@interface NSObject (Bar)
-(void)wibble;
@end

int main(void)
{
  CREATE_AUTORELEASE_POOL(pool);

  Foo *f= [Foo new];
  [f wibble];

  IMP i = class_getMethodImplementation([f class], @selector(wibble));
  NSLog(@"IMP: %p\n", i);
  i(f, @selector(wibble));

  [f performSelector: @selector(wibble)];
  RELEASE(pool);
  return 0;
}

This still leaves your problem open. I expect that the real issues has to do with the compiler not knowing about the signature of the method you are sending. To better understand this we will need to see more of your code. Could you try to extend the above program until it reprocudes the problem you are seeing?
And the most likely solution will be that you class needs to implement +methodSignatureForSelector:

Hi Fred,

It seems like you're correct. At least, Apple runtime reference documentation explicitly states that class_getMessageImplementation() might return a pointer to `a part of the runtime's message forwarding machinery'. So we technically would need to modify the behaviour of our runtime to be compatible with the Apple implementation.

Since that is a bit tedious (since it means juggling around with varargs and various places where the return value might end up), my is a take on this issue is that we should, in the meantime, do two things:

a) Don't raise an exception in gs_objc_msg_forward2(), just return NULL if we cannot get a signature to construct a cframe for. The function is a hook for the runtime, which should tolerate if the forwarding mechanism doesn't come up with a sensible match.

b) Amend our implementation of `-performSelector:' to just use objc_msg_lookup() and call the returned IMP. This is what a message send compiles to anyways, which (I think) should be more robust than the present code that calls class_getMethodImplementation(). But then again I might be missing the reason why we did it that way in the first place...

Cheers,

Niels

Here is the relevant part of the traceback (obtained with base-1.24): You can see that the class passed to class_getMethodImplementation is the value of the receiver parameter passed to gs_objc_msg_forward2.

#2  0x005babe3 in +[NSException raise:format:] (self=0x88ca60, _cmd=0x8dd778, name=0x88cd18, format=0x8dd8d0) at NSException.m:835
#3  0x006df05b in gs_objc_msg_forward2 (receiver=0x1b8cbc0, sel=0x80d10f0) at GSFFIInvocation.m:197
#4  0x00922433 in get_imp () from /usr/lib/i386-linux-gnu/libobjc.so.2
#5  0x006e0538 in class_getMethodImplementation (cls=0x1b8cbc0, name=0x80d10f0) at runtime.c:496
#6  0x00616548 in -[NSObject performSelector:] (self=0x82e217c, _cmd=0x1b88908, aSelector=0x80d10f0) at NSObject.m:1976

Which libobjc are you using? I checked with the old GNUstep libobjc and the new libobjc2 and in neither case could I follow you call sequence.
Still the bug you report look plausible, we seem to be loosing information that would be valuable for the forwarding.