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

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

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

> 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

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

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

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

On 12 Feb 2018, at 22:31, Stanislav Pankevich via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > 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

> On 13 Feb 2018, at 17:42, Stanislav Pankevich <s.pankevich at gmail.com> wrote: > > On Tue, Feb 13, 2018 at 12:18 PM, David Chisnall > <David.Chisnall at cl.cam.ac.uk> wrote: >> On 12 Feb 2018, at 22:31, Stanislav Pankevich via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> Specifically I explored the latest objc4-723 >>>

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

Hi Stanislav, Sorry -- I am not much help here. I would like to get ObjC runtime support for the JIT, but have not had time to look in to it closely. When I last tested the idea (a couple of years ago now) we used selector registration and objc_readClassPair to get basic test cases working as you have, but ran into (possibly similar) failures on non-trivial test cases. I think the interpretation

On Tue, Feb 13, 2018 at 12:18 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > On 12 Feb 2018, at 22:31, Stanislav Pankevich via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> 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,

Hello, It is likely that I missing something however I have to ask. We are working on Mull project https://github.com/mull-project which deals with LLVM IR in the first place so it is often that we encounter errors like the following one when we do things like parseAssemblyString(IR, Err, GlobalCtx);`: ``` test: <string>:7237:187: error: invalid field 'variable' !1526 = distinct

Hi all, I am having hard time figuring out how I should use the API for JIT in LLVM 6. In LLVM 3.9 I am used to adding all objects at once and emitAndFinalizing them all: handle = objectLayer.addObjectSet(objectFiles, memoryManager, resolver); objectLayer.emitAndFinalize(handle); In LLVM 6.0 the objects are added one by one: auto handle = objectLayer.addObject(objectFile, resolver).get();

Hi, Is it possible to run Objective-C code in lli? lli does not seem to want to load Foundation.framework. Please see below. Thanks, Eric Brunstad #import <Foundation/Foundation.h> int main(int argc, char *argv[]) { NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; NSLog(@"test!"); [pool drain]; return EXIT_SUCCESS; } cmu-351714:llvm-2.5 ericbrunstad$

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

On Oct 18, 2009, at 6:32 PM, Eric Brunstad wrote: > Hi, > > Is it possible to run Objective-C code in lli? lli does not seem to > want to load Foundation.framework. It is definitely possible, but we're not there yet. LLI would have to know about objective-c metadata to register it properly with the runtime. This is important for things like classes etc. This isn't

Sorry if this isn't the right place; but I'm facing an XCode 4 (LLVM 2.0 to Apple, I heard it's LLVM 2.9 under the hood) issue that may involve LLVM, and maybe some people on this list could help me short-circuit the source. I have a code pattern that, when used in XCode 4 in Objective C++ files, causes the whole IDE to go crash. It is a stripped sample to highlight the issue. In

Hi, What would be an estimate for the amount of work required to implement this? Where would I get started if I were to implement it? My goal is to run Objective-C programs in the interpreter so I can provide an application-sandbox by disallowing the invocation of certain C-functions and also by disallowing the invocation of certain Objective-C methods. Thanks, Eric On Oct 19, 2009,

Hi there, I'm trying to run trivial Objective-C code that uses the Foundation framework under MacOS X in lli. It seems that the code will compile and run using llc, however fails to work in lli. SimpleFoundation.m: ---- #import <Foundation/Foundation.h> int main (int argc, const char * argv[]) { NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init]; // insert code

Full_Name: Chris Pelton Version: R-1.5.0 OS: Solaris & Submission from: (NULL) (169.237.121.210) I am unable to compile R-1.5.0, and am getting the following errors with make. I searched through the buglist and didn't see anything similar, although I wouldn't doubt if I was just using the wrong version of something. gcc version 3.0.3 gcc -I. -I../../src/include