logos icon indicating copy to clipboard operation
logos copied to clipboard

Take advantage of weak linking

Open kirb opened this issue 5 years ago • 1 comments

%c() has shortcomings — for instance the compiler has no idea what type it actually is and can’t do type checking on instancetype methods, forcing use of casts like this:

[(SpringBoard *)[%c(SpringBoard) sharedApplication] doThing];
((SpringBoard *)[%c(SpringBoard) sharedApplication]).isThingDone; // even worse!

Clang supports a weak_import attribute on classes that allows us to skip the linker trying to find the symbol to link, and allows the symbol to be optional just as %c() is.

Which would allow much more elegant code, like maybe:

%weakclass SpringBoard;

// …

[[SpringBoard sharedApplication] doThing];
[SpringBoard sharedApplication].isThingDone;

%weakclass X would expand to:

__attribute__((weak_import))
@interface SpringBoard ()
@end

Of course these weak symbols will be resolved at process launch time/library load time just like every other symbol dyld needs to resolve, so %c() is still necessary for late-loaded symbols.

To discuss:

Does this work on a category interface? Worst case scenario, we generate a separate file containing flags to pass the linker for weak import, or use this:

asm(".weak_reference _OBJC_CLASS_$_SpringBoard");

According to this thread the attribute method may require a linker flag anyway due to a limitation of the implementation. I’m really hoping this is a bug and that it’s fixed now, so we can use an #if directive to check the clang version and #error out if it’s a known broken version.

kirb avatar Dec 26 '18 01:12 kirb

I think I originally misunderstood the entire purpose of weak_import in the first place. From some old Apple Support forum:

iOS and OS X use a "two level namespace" for symbol binding. That means the static linker records from which dylib each undefined symbol was found. At launch time, dyld uses that info to search for that symbol only in that dylib. The use of weak_import means the symbol might be missing at runtime—but still, it must be found at build time (to record the dylib it might be in at runtime). This is different than ELF system were "weak" means the linker won't complain if no definition is found.

There are compiler flags to get around this, but they either require flags for specific symbols in question (yuck) or opting into dynamic_lookup behavior for all undefined symbols, unfortunately:

  1. -U <symbol> where <symbol> is something like _OBJC_CLASS_$_SomeClass
  2. -undefined dynamic_lookup which means all undefined symbols are looked up by dyld.

Because of 2., we know the functionality we want is possible; that is, dyld will happily search all images for a symbol. I've tested it. Sample code:

#include <stdio.h>
#import <Foundation/NSObject.h>

__attribute__((weak_import))
@interface NSArray : NSObject
+ (instancetype)new;
@end

int main() {
    id obj = [NSArray new];
    if (obj) {
        printf("Success\n");
    } else {
        printf("Failure\n");
    }

    return 0;
}

Note that the weak_import attribute is required; all it does is tell dyld to ignore runtime linking errors. Without it, the code will still compile, but it will crash. Anyway, compiled with clang main.m -lobjc -undefined dynamic_lookup -o foo, tested like so:

$ ./foo
Failure
$ DYLD_INSERT_LIBRARIES=/System/Library/Frameworks/Cocoa.framework/Cocoa ./foo
Success

As expected, compiling without -undefined dynamic_lookup yields

Undefined symbols for architecture x86_64:
  "_OBJC_CLASS_$_NSArray", referenced from:
      objc-class-ref in main-97d90b.o
ld: symbol(s) not found for architecture x86_64

It is simply unfortunate that this isn't a language feature yet :/

NSExceptional avatar Dec 26 '18 03:12 NSExceptional