Is it possible to execute Objective-C code via LLVM JIT?

Stanislav_Pankevich · October 18, 2016, 8:33pm

Hello,

Is it possible to execute Objective-C code using LLVM JIT?

The original point for my research is this topic on StackOverflow:

All selectors unrecognised when invoking Objective-C methods using the LLVM ExecutionEngine http://stackoverflow.com/questions/10375324/all-selectors-unrecognised-when-invoking-objective-c-methods-using-the-llvm-exec

Running that example with lli produces the following output:

2016-10-18 21:25:58.332 lli[12970:169282] *** NSForwarding: warning: selector (0x10356a38f) for message ‘alloc’ does not match selector known to Objective C runtime (0x7fff8e93afb5)-- abort
2016-10-18 21:25:58.334 lli[12970:169282] +[NSAutoreleasePool alloc]: unrecognized selector sent to class 0x7fff7a562130
2016-10-18 21:25:58.338 lli[12970:169282] *** Terminating app due to uncaught exception ‘NSInvalidArgumentException’, reason: ‘+[NSAutoreleasePool alloc]: unrecognized selector sent to class 0x7fff7a562130’

See also additional discussion here: https://twitter.com/sbpankevich/status/783363161537798144.

Thanks.

Stanislav Pankevich

lhames · October 18, 2016, 9:10pm

Hi Stanislav,

I actually looked into this recently. It is possible, but takes some non-trivial effort right now: You have to hook into the JIT memory allocator, parse the objective C metadata sections in the object file, then call the objective C runtime to register any newly added classes, protocols and selectors.

I can’t release my code as-is: I built it against a hacked up copy of the runtime. The right way to do this would be to write parsers for the objective C metadata, and an Objective-C registration call that uses the parsers and calls the runtime. These should be made available conditionally if the objective C runtime headers are available. This is something that I’d like to get to eventually, but I have a long to-do list. If you or anyone you know is interested in working on it I’d be happy to provide pointers and code review.

Cheers,
Lang.

cachemeifyoucan · October 18, 2016, 9:22pm

Hi Stanislav, Lang

I have a version of objc metadata parser based on LLVM which can handle objc2 metadata from MachO object and bitcode (bitcode version is even swift compatible). I don’t know if there is enough interest for me to upstream it. It probably requires some work to clean up the interface and complete it by adding objc1 support and other object format support.

Steven

lhames · October 18, 2016, 11:49pm

Hi Steven,

That sounds great. The object file parser would definitely be of interest to JIT clients. Having ObjC 1 support would be nice, but I don’t see it as a blocker to committing what you’ve got: all code produced by the JIT is going to be ObjC-2.

Cheers,
Lang.

Stanislav_Pankevich · October 19, 2016, 6:28pm

Hi Lang, Steven,

At this point it seems that the best next step is for Steven to share his code, right? Or is there some other work that can be done in parallel?

Lang? Steven?

Here’s small note about my interest here: Alex Denisov and I are working on a tool for mutation testing https://github.com/AlexDenisov/mutang. Alex has made fascinating progress towards mutation testing of C++ code and we would also like to bring mutation testing to iOS where we are by profession. Currently inability to run Objective-C code via JIT is a critical dependency for our progress on iOS part so I’ll be happy to help with this in any way even though my experience with LLVM is very limited.

Thanks.

Stanislav

cachemeifyoucan · October 20, 2016, 6:57pm

Hi Lang, Steven,

At this point it seems that the best next step is for Steven to share his code, right? Or is there some other work that can be done in parallel?

It will take some time to create patch from my existing implementation. After that, we still need to correctly register the implementation to objc runtime. I dont expect this to be a quick task.

Lang? Steven?

Here’s small note about my interest here: Alex Denisov and I are working on a tool for mutation testing https://github.com/AlexDenisov/mutang. Alex has made fascinating progress towards mutation testing of C++ code and we would also like to bring mutation testing to iOS where we are by profession. Currently inability to run Objective-C code via JIT is a critical dependency for our progress on iOS part so I’ll be happy to help with this in any way even though my experience with LLVM is very limited.

This sounds like an interesting project. Maybe you can generate the object file and statically linked the mutated code for now?

Steven

Thanks.

Stanislav

Hi Steven,

That sounds great. The object file parser would definitely be of interest to JIT clients. Having ObjC 1 support would be nice, but I don’t see it as a blocker to committing what you’ve got: all code produced by the JIT is going to be ObjC-2.

So no JIT for i386?

Steven

Stanislav_Pankevich · October 20, 2016, 9:09pm

Hi Lang, Steven,

At this point it seems that the best next step is for Steven to share his code, right? Or is there some other work that can be done in parallel?

It will take some time to create patch from my existing implementation. After that, we still need to correctly register the implementation to objc runtime. I dont expect this to be a quick task.

I will be happy to help with anything that could help to push this forward especially with a guidance from you and Lang. As for us, the time is not really critical as we have a lot of other things to cover, however once there will be something that we could help with here, feel free to distribute any work to me and Alex.

Lang? Steven?

Here’s small note about my interest here: Alex Denisov and I are working on a tool for mutation testing https://github.com/AlexDenisov/mutang. Alex has made fascinating progress towards mutation testing of C++ code and we would also like to bring mutation testing to iOS where we are by profession. Currently inability to run Objective-C code via JIT is a critical dependency for our progress on iOS part so I’ll be happy to help with this in any way even though my experience with LLVM is very limited.

This sounds like an interesting project. Maybe you can generate the object file and statically linked the mutated code for now?

Unfortunately that’s not how this project is supposed to work. The algorithm that is already working for C++ is roughly the following:

We compile original test suite with its system under test, then run the test suite before doing any mutations, record the result.
We make 1 mutation in one module, recompile only that module, replace original module with mutated one, run them again using JIT, record the results of running a mutated version.
Repeat step 2 many times (in order of thousand times and more), collect the statistics.
Observe results.

So given the following procedure it makes the most of sense to use JIT. As I said this is working perfectly for C++ already and now we are very excited about the opportunity to bring the same to iOS.

lhames · October 22, 2016, 1:21am

So no JIT for i386?

I didn’t realise i386 still used ObjC 1 - all my experiments were on arm64.

i386 support for ObjC would be nice to have, but it’s not a blocker for adding ObjC 2 support.

Lang.

Stanislav_Pankevich · November 10, 2016, 10:03pm

Hi Lang, Steven,

Any updates on this? Steven, is there a progress with metadata parser for Objective-C?

Let us know if we can help somehow.

Thanks.

Stanislav

David_Chisnall3 · November 11, 2016, 9:57am

A few years ago, I put together a proof-of-concept implementation of CGObjCRuntime that emitted a load function that called out to the runtime’s functions for registering selectors, generating classes, adding methods, and so on. I don’t have the code anymore (and it’s probably bitrotted to the extent that a clean reimplementation would probably be easier), but it was only a few hundred lines of code and would work with any Objective-C runtime in a JIT context.

David

cachemeifyoucan · November 11, 2016, 9:26pm

Hi Stanislav

Thanks for checking on this. If you want a quick hack, you can try to read the code in tools/llvm-objdump/MachODump.cpp. There are some c code in there to parse metadata.

My code is something I put up for my own purpose for debugging/parsing objc metadata. The interface is a bit rough to use but the biggest problem is testing. I have my own binary living out of tree to test the parser but it doesn’t make sense to have another parser in tree to do the same thing. I really hope I can replace the code in MachODump, but unfortunately the current error handling model in libObject prevents me from replicate all the functions in MachODump. We are working towards that direction but we are not there yet. In the meantime, I won’t mind posting some patches when I have time.

Steven

Kevin_Enderby · November 11, 2016, 9:38pm

Just a comment here. The code in tools/llvm-objdump/MachODump.cpp has requirements beyond being able to parse the Objective-C for the machine it is running on. It must work cross byte sex, with differing alignment, dealing with both Objc1 & Objc2, pointers of the non-native size and not the native addresses and be robust enough to not crash with bad meta data. So while it parses the Objective-C meta data it likely is not a good model for execution.

Kev

cachemeifyoucan · November 11, 2016, 9:45pm

Hi Kevin

I am just pointing out that is a good place to look at how metadata is parsed and it supports parsing metadata from pre-linked object file which is important to JIT.

My code pretty much replicate most of the functions in MachODump in C++ and hope it can much more reusable than the c parser. The biggest missing part is the resilience to bad metadata due to the fact we currently don’t have good way to recover from error but I know Chris B is working on something like that. I will definitely ask more feedback from you when I feel like my code is ready.

Thanks

Steven

Stanislav_Pankevich · February 12, 2018, 10:31pm

Hi all,

I actually looked into this recently. It is possible, but takes some non-trivial effort right now: You have to hook into the JIT memory allocator, parse the objective C metadata sections in the object file, then call the objective C runtime to register any newly added classes, protocols and selectors.
I can't release my code as-is: I built it against a hacked up copy of the runtime. The right way to do this would be to write parsers for the objective C metadata, and an Objective-C registration call that uses the parsers and calls the runtime. These should be made available conditionally if the objective C runtime headers are available. This is something that I'd like to get to eventually, but I have a long to-do list. If you or anyone you know is interested in working on it I'd be happy to provide pointers and code review.

Has any progress been made on this issue since 1 year ago?

Lang, I have spent some time trying to follow your hints along the
lines quoted above and found that it is indeed a non-trivial effort to
implement all of this. Specifically I explored the latest objc4-723
from Apple Open Source and it looks like all of the APIs that allow
the registration of Objective-C classes, selectors, etc. are all very
private.

One year ago you said you could help anyone interested in working on
this. Let me check here again as a volunteer (if this work can ever be
accomplished by someone outside Apple).

[cutting the rest of the thread to reduce the size of the email]

Thanks,

Stanislav

David_Chisnall3 · February 13, 2018, 11:18am

Specifically I explored the latest objc4-723
from Apple Open Source and it looks like all of the APIs that allow
the registration of Objective-C classes, selectors, etc. are all very
private.

The Objective-C runtime provides public APIs for doing all of this. They’re even documented. They are also more or less standard and so work with all runtime implementations, not just the Apple one. I was using them for JIT’d code on macOS and FreeBSD 10 years ago.

One year ago you said you could help anyone interested in working on
this. Let me check here again as a volunteer (if this work can ever be
accomplished by someone outside Apple).

As I said in the earlier thread, the best way of doing this is to add a new subclass of CGObjCRuntime that generates the code using the public APIs. If you’re running in the same process as the JIT, you could register the selectors in the host environment and just inject the values as symbols (this is what I did). I’d be happy to help out someone who wants to do this.

David

Stanislav_Pankevich · February 13, 2018, 5:42pm

Specifically I explored the latest objc4-723
from Apple Open Source and it looks like all of the APIs that allow
the registration of Objective-C classes, selectors, etc. are all very
private.

The Objective-C runtime provides public APIs for doing all of this. They’re even documented. They are also more or less standard and so work with all runtime implementations, not just the Apple one. I was using them for JIT’d code on macOS and FreeBSD 10 years ago.

Which methods are you referring to? For example of class registration,
do you mean objc_allocateClassPair/objc_registerClassPair or something
else?

One year ago you said you could help anyone interested in working on
this. Let me check here again as a volunteer (if this work can ever be
accomplished by someone outside Apple).

As I said in the earlier thread, the best way of doing this is to add a new subclass of CGObjCRuntime that generates the code using the public APIs.

Let me get this right. What clang::CodeGen:: CGObjCRuntime has to do
with this? My understanding of Lang's hint was that one has to extend
llvm's classes like RuntimeDyldMachO to parse Mach-O, find classes,
selectors, categories etc and register them all manually. Are you
saying that something has to be be added to CodeGen/*?

If you’re running in the same process as the JIT, you could register the selectors in the host environment and just inject the values as symbols (this is what I did). I’d be happy to help out someone who wants to do this.

It would be nice to get this working without embedding any of
Objective-C to the host process this is why I am particularly
interested in knowing how to do the work that objc4 does in the
methods such as: objc4/_objc_init, objc4/map_images_nolock and
objc4/_read_images.

My understanding of the goal is to make the lli example from this
thread working:
https://stackoverflow.com/questions/10375324/all-selectors-unrecognised-when-invoking-objective-c-methods-using-the-llvm-exec.

I would be happy to get a hint on which functions of Objective-C
Runtime's public API should I use to get that simple example working
in a quick and dirty way.

Thanks.

David_Chisnall3 · February 14, 2018, 11:08am

Specifically I explored the latest objc4-723
from Apple Open Source and it looks like all of the APIs that allow
the registration of Objective-C classes, selectors, etc. are all very
private.

The Objective-C runtime provides public APIs for doing all of this. They’re even documented. They are also more or less standard and so work with all runtime implementations, not just the Apple one. I was using them for JIT’d code on macOS and FreeBSD 10 years ago.

Which methods are you referring to? For example of class registration,
do you mean objc_allocateClassPair/objc_registerClassPair or something
else?

Yes, those set of APIs. They provide an interface for building classes, protocols, and so on.

One year ago you said you could help anyone interested in working on
this. Let me check here again as a volunteer (if this work can ever be
accomplished by someone outside Apple).

As I said in the earlier thread, the best way of doing this is to add a new subclass of CGObjCRuntime that generates the code using the public APIs.

Let me get this right. What clang::CodeGen:: CGObjCRuntime has to do
with this? My understanding of Lang's hint was that one has to extend
llvm's classes like RuntimeDyldMachO to parse Mach-O, find classes,
selectors, categories etc and register them all manually. Are you
saying that something has to be be added to CodeGen/*?

You have two options:

1) Hack up something in RuntimeDyldMachO to handle the data structures currently generated by clang. This is fragile, because the interface between the compiler and the runtime is not documented, and is unique to each runtime. This code will be different on i386 and ARM, for example.

2) Create a new CGObjCRuntime subclass that creates a module init function that constructs all of the classes using the public APIs, by adding something like -fobjc-runtime=jit to the clang flags. This is not particularly difficult and means that the same code can be used with any Objective-C runtime.

If you’re running in the same process as the JIT, you could register the selectors in the host environment and just inject the values as symbols (this is what I did). I’d be happy to help out someone who wants to do this.

It would be nice to get this working without embedding any of
Objective-C to the host process this is

It’s an optimisation, not a compulsory part of the process.

why I am particularly
interested in knowing how to do the work that objc4 does in the
methods such as: objc4/_objc_init, objc4/map_images_nolock and
objc4/_read_images.

My understanding of the goal is to make the lli example from this
thread working:
https://stackoverflow.com/questions/10375324/all-selectors-unrecognised-when-invoking-objective-c-methods-using-the-llvm-exec.

I would be happy to get a hint on which functions of Objective-C
Runtime's public API should I use to get that simple example working
in a quick and dirty way.

You seem to have decided that you want to use unmodified IR from a specific version of Apple's Objective-C implementation. I can’t help you there.

David

Nat · February 14, 2018, 1:55pm

If you'd link "lli" with the Cocoa framework, wouldn't dyld do all the appropriate runtime setup stuff for lli and you'd be all set ?

I haven't tried it myself.

Ciao
Nat!

P.S. Can't help myself to mention, that I would expect none of these JIT problems with the mulle-objc runtime, since it does use module init functions and doesn't rely on any special linker stuff. But it won't run Cocoa for you for sure...

lhames · February 15, 2018, 1:33am

Hi David, Stanislav,

Sorry for the delayed reply.

Short version: There hasn’t been any progress on this just yet, as I have been busy with an overhaul of the underlying ORC APIs.

Hack up something in RuntimeDyldMachO to handle the data structures currently generated by clang. This is fragile, because the interface between the compiler and the runtime is not documented, and is unique to each runtime. This code will be different on i386 and ARM, for example.

Create a new CGObjCRuntime subclass that creates a module init function that constructs all of the classes using the public APIs, by adding something like -fobjc-runtime=jit to the clang flags. This is not particularly difficult and means that the same code can be used with any Objective-C runtime.

(1) is the preferred long-term solution as we want to minimize differences between generated code in the JIT’d and non-JIT’d cases. (2) seems like a reasonable interim solution if it is easier to implement.

Steven – what is the status of the ObjC parsing code these days?

– Lang.

Stanislav_Pankevich · April 6, 2018, 7:19pm

Hi again,

I had tried to follow David's suggestion to take a step back and look
into codegen instead of hacking on RuntimeDyld but then I quickly
realized that I don't understand what exactly needs to be done to
fully register Objective-C runtime. I decided to iterate on JIT code
again and somehow I found that I can hook into SectionMemory by
subclassing it and working with its allocateDataSection method:

1) I collect pointers to objc-related sections for which the memory is
allocated. Before SectionMemoryManager::finalizeMemory() method is
called I register the ObjC runtime classes.
2) I iterate over __objc_selrefs sections and fixup selectors. This
does fix the original crash of this thread.
3) I iterate over __objc_classlist sections and register the new
classes using objc_allocateClassPair function, register the properties
and ivars to these new classes, run objc_registerClassPair to complete
the registration. (I still have to implement the protocol
registration)
4) I iterate over __objc_classrefs and __objc_superrefs and fix up the
class pointers with the new classes created at step 2.
5) I iterate over __objc_classlist and fix up its classes with the new
classes created at step 2.

The very basic Objective-C code seems to work now without any issues,
however when I switch to mixed Objective-C/Swift code I start getting
some crashes which I don't fully understand. In particular I am trying
to run a simple XCTestCase test written in Swift and my code crashes
when I access the property of this Swift's ObjC-based class.

My questions are:

1) Should I do anything else to properly register Objective-C besides
what I am doing at steps 1-5?

2) Do I have to do anything additionally to make run Swift code with
LLVM JIT? On of the attached files show that the object I am working
with has sections like: __swift3_* or __swift2_*. Should I do anything
about this sections or they are irrelevant?

3) Anything that I am missing / should know about if I want to run
mixed Objective-C/Swift code via LLVM JIT?

My very hacky code is located here [1]. If needed I can also share the
code of my latest attempts to run the combined ObjC/Swift code.

Any help very much appreciated.

Stanislav