Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Take advantage of weak linking #29

Open
kirb opened this issue Dec 26, 2018 · 1 comment
Open

Take advantage of weak linking #29

kirb opened this issue Dec 26, 2018 · 1 comment
Labels
enhancement New feature or request needs discussion Theos team needs to discuss a solution

Comments

@kirb
Copy link
Member

kirb commented Dec 26, 2018

%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 kirb added enhancement New feature or request needs discussion Theos team needs to discuss a solution labels Dec 26, 2018
@NSExceptional
Copy link
Contributor

NSExceptional commented Dec 26, 2018

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 :/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request needs discussion Theos team needs to discuss a solution
Projects
None yet
Development

No branches or pull requests

2 participants