search for: cgobjcruntim

...ted. The mechanics of interpretation are rather complicated, and for a start, I would like to stay way from that. Thus, I have chosen to JIT only expressions, but not blocks (yet). My question are: 1. Do you think it would make sense to use the clang codebase (specifically Objective-C CodeGen / CGObjCRuntime) in order to generate the code that will replace F-Script's interpretation? If that is possible it would enable me to start progressively porting F-Script to LLVM, instead of reinventing the wheel and port everything at once. 2. If the previous answer is yes, can you point me to some code wh...

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

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

...untimeDyldMachO 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. (1...

...gt; 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 regis...

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

On Mon, Jun 1, 2009 at 4:25 AM, Camille Troillard<camille at osculator.net> wrote: > 1. Do you think it would make sense to use the clang codebase (specifically > Objective-C CodeGen / CGObjCRuntime) in order to generate the code that will > replace F-Script's interpretation?  If that is possible it would enable me > to start progressively porting F-Script to LLVM, instead of reinventing the > wheel and port everything at once. It's a possibility, but I'm not sure how mu...

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

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

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

> 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