llvm dev - Oct 2016 - Is it possible to execute Objective-C code via LLVM JIT?

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
<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
> On 19 Oct 2016, at 01:49, Lang Hames <lhames at gmail.com> wrote:
> 
> 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.
> 
> On Tue, Oct 18, 2016 at 2:22 PM, Steven Wu <stevenwu at apple.com
<mailto:stevenwu at apple.com>> wrote:
> 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
> 
>> On Oct 18, 2016, at 2:10 PM, Lang Hames via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> 
>> 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.
>> 
>> On Tue, Oct 18, 2016 at 1:33 PM, Stanislav Pankevich via llvm-dev
<llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
wrote:
>> 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
<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
<https://twitter.com/sbpankevich/status/783363161537798144>.
>> 
>> Thanks.
>> 
>> Stanislav Pankevich
>> 
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>> 
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161019/d313e592/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161019/d313e592/attachment-0001.sig>

> On Oct 19, 2016, at 11:28 AM, Stanislav Pankevich <s.pankevich at
gmail.com> wrote:
> 
> 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
<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
> 
>> On 19 Oct 2016, at 01:49, Lang Hames <lhames at gmail.com
<mailto:lhames at gmail.com>> wrote:
>> 
>> 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
>> 
>> Cheers,
>> Lang.
>> 
>> On Tue, Oct 18, 2016 at 2:22 PM, Steven Wu <stevenwu at apple.com
<mailto:stevenwu at apple.com>> wrote:
>> 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
>> 
>>> On Oct 18, 2016, at 2:10 PM, Lang Hames via llvm-dev <llvm-dev
at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>> 
>>> 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.
>>> 
>>> On Tue, Oct 18, 2016 at 1:33 PM, Stanislav Pankevich via llvm-dev
<llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
wrote:
>>> 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
<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
<https://twitter.com/sbpankevich/status/783363161537798144>.
>>> 
>>> Thanks.
>>> 
>>> Stanislav Pankevich
>>> 
>>> 
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>>> 
>>> 
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>> 
>> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161020/393aac8e/attachment.html>

> On 20 Oct 2016, at 20:57, Steven Wu <stevenwu at apple.com> wrote:
> 
> 
> 
>> On Oct 19, 2016, at 11:28 AM, Stanislav Pankevich <s.pankevich at
gmail.com <mailto:s.pankevich at gmail.com>> wrote:
>> 
>> 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
<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:

1. We compile original test suite with its system under test, then run the test
suite before doing any mutations, record the result.
2. 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.
3. Repeat step 2 many times (in order of thousand times and more), collect the
statistics.
4. 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.
> Steven
> 
>> 
>> Thanks.
>> 
>> Stanislav
>> 
>>> On 19 Oct 2016, at 01:49, Lang Hames <lhames at gmail.com
<mailto:lhames at gmail.com>> wrote:
>>> 
>>> 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
> 
>>> 
>>> Cheers,
>>> Lang.
>>> 
>>> On Tue, Oct 18, 2016 at 2:22 PM, Steven Wu <stevenwu at
apple.com <mailto:stevenwu at apple.com>> wrote:
>>> 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
>>> 
>>>> On Oct 18, 2016, at 2:10 PM, Lang Hames via llvm-dev
<llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
wrote:
>>>> 
>>>> 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.
>>>> 
>>>> On Tue, Oct 18, 2016 at 1:33 PM, Stanislav Pankevich via
llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
>>>> 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
<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
<https://twitter.com/sbpankevich/status/783363161537798144>.
>>>> 
>>>> Thanks.
>>>> 
>>>> Stanislav Pankevich
>>>> 
>>>> 
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>>>> 
>>>> 
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>>> 
>>> 
>> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161020/20b59950/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161020/20b59950/attachment.sig>

> 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.


On Thu, Oct 20, 2016 at 11:57 AM, Steven Wu <stevenwu at apple.com> wrote:
>
>
>
> On Oct 19, 2016, at 11:28 AM, Stanislav Pankevich <s.pankevich at
gmail.com>
> wrote:
>
> 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
>
> On 19 Oct 2016, at 01:49, Lang Hames <lhames at gmail.com> wrote:
>
> 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
>
>
> Cheers,
> Lang.
>
> On Tue, Oct 18, 2016 at 2:22 PM, Steven Wu <stevenwu at apple.com>
wrote:
>
>> 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
>>
>> On Oct 18, 2016, at 2:10 PM, Lang Hames via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>> 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.
>>
>> On Tue, Oct 18, 2016 at 1:33 PM, Stanislav Pankevich via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> 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/sbpa
>>> nkevich/status/783363161537798144.
>>>
>>> Thanks.
>>>
>>> Stanislav Pankevich
>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161021/28e07675/attachment.html>