<div dir="ltr">Hi David, Stanislav,<div><br></div><div>Sorry for the delayed reply.</div><div><br></div><div>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.</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">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.<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">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.</blockquote></div><div><br></div><div>(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.</div><div><br></div><div>Steven -- what is the status of the ObjC parsing code these days?</div><div><br></div><div>-- Lang.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 14, 2018 at 3:08 AM, David Chisnall via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On 13 Feb 2018, at 17:42, Stanislav Pankevich <<a href="mailto:s.pankevich@gmail.com">s.pankevich@gmail.com</a>> wrote:<br>
><br>
> On Tue, Feb 13, 2018 at 12:18 PM, David Chisnall<br>
> <<a href="mailto:David.Chisnall@cl.cam.ac.uk">David.Chisnall@cl.cam.ac.uk</a>> wrote:<br>
>> On 12 Feb 2018, at 22:31, Stanislav Pankevich via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
>>><br>
>>> Specifically I explored the latest objc4-723<br>
>>> from Apple Open Source and it looks like all of the APIs that allow<br>
>>> the registration of Objective-C classes, selectors, etc. are all very<br>
>>> private.<br>
>><br>
>> 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.<br>
><br>
> Which methods are you referring to? For example of class registration,<br>
> do you mean objc_allocateClassPair/objc_<wbr>registerClassPair or something<br>
> else?<br>
<br>
</span>Yes, those set of APIs. They provide an interface for building classes, protocols, and so on.<br>
<span class=""><br>
>>> One year ago you said you could help anyone interested in working on<br>
>>> this. Let me check here again as a volunteer (if this work can ever be<br>
>>> accomplished by someone outside Apple).<br>
>><br>
>> 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.<br>
><br>
> Let me get this right. What clang::CodeGen:: CGObjCRuntime has to do<br>
> with this? My understanding of Lang's hint was that one has to extend<br>
> llvm's classes like RuntimeDyldMachO to parse Mach-O, find classes,<br>
> selectors, categories etc and register them all manually. Are you<br>
> saying that something has to be be added to CodeGen/*?<br>
<br>
</span>You have two options:<br>
<br>
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.<br>
<br>
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.<br>
<span class=""><br>
>> 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.<br>
><br>
> It would be nice to get this working without embedding any of<br>
> Objective-C to the host process this is<br>
<br>
</span>It’s an optimisation, not a compulsory part of the process.<br>
<span class=""><br>
> why I am particularly<br>
> interested in knowing how to do the work that objc4 does in the<br>
> methods such as: objc4/_objc_init, objc4/map_images_nolock and<br>
> objc4/_read_images.<br>
><br>
> My understanding of the goal is to make the lli example from this<br>
> thread working:<br>
> <a href="https://stackoverflow.com/questions/10375324/all-selectors-unrecognised-when-invoking-objective-c-methods-using-the-llvm-exec" rel="noreferrer" target="_blank">https://stackoverflow.com/<wbr>questions/10375324/all-<wbr>selectors-unrecognised-when-<wbr>invoking-objective-c-methods-<wbr>using-the-llvm-exec</a>.<br>
><br>
> I would be happy to get a hint on which functions of Objective-C<br>
> Runtime's public API should I use to get that simple example working<br>
> in a quick and dirty way.<br>
<br>
</span>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.<br>
<br>
David<br>
<div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div>