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

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

> On Nov 10, 2016, at 2:03 PM, Stanislav Pankevich <s.pankevich at
gmail.com> wrote:
> 
> 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
> 
>> On 22 Oct 2016, at 03:21, Lang Hames <lhames at gmail.com
<mailto:lhames at gmail.com>> wrote:
>> 
>> > 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
<mailto: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.
>> 
>>> 
>>> 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/20161111/2adb685c/attachment.html>

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
> On Nov 11, 2016, at 1:26 PM, Steven Wu via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 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
> 
> 
>> On Nov 10, 2016, at 2:03 PM, Stanislav Pankevich <s.pankevich at
gmail.com <mailto:s.pankevich at gmail.com>> wrote:
>> 
>> 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
>> 
>>> On 22 Oct 2016, at 03:21, Lang Hames <lhames at gmail.com
<mailto:lhames at gmail.com>> wrote:
>>> 
>>> > 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 <mailto: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.
>>> 
>>>> 
>>>> 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>
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>> 
> 
> _______________________________________________
> 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/20161111/82c32d40/attachment.html>

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
> On Nov 11, 2016, at 1:38 PM, Kevin Enderby <enderby at apple.com>
wrote:
> 
> 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
> 
>> On Nov 11, 2016, at 1:26 PM, Steven Wu via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> 
>> 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
>> 
>> 
>>> On Nov 10, 2016, at 2:03 PM, Stanislav Pankevich <s.pankevich at
gmail.com <mailto:s.pankevich at gmail.com>> wrote:
>>> 
>>> 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
>>> 
>>>> On 22 Oct 2016, at 03:21, Lang Hames <lhames at gmail.com
<mailto:lhames at gmail.com>> wrote:
>>>> 
>>>> > 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 <mailto: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.
>>>> 
>>>>> 
>>>>> 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>
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>> 
>> _______________________________________________
>> 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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161111/df504fbb/attachment.html>