similar to: [LLVMdev] Trouble Resolving Objective-C Symbols in lli

On Thu, 19 Jul 2007, Andy Kitchen wrote: > 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. Nice! this is a great project, unfortunately, there are some issues here :) I'm CC'ing Marcel, as he has some experience with

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$

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

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 Chris, > Once you have that, you are hitting another problem. Specifically, > the JIT::getPointerToNamedFunction method in > lib/ExecutionEngine/JIT/Intercept.cpp just does a dlsym on missing > symbols. If dlsym returns null, you get the error message. > > The problem here is that .objc_class_name_* are special symbols that > are used by the objc linker support and they

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 Ralph, On Fri, 2007-07-20 at 10:38 +0100, Ralph Corderoy wrote: > Hi Chris, > I could be missing something, but shouldn't the use of dlsym() be > > char *err; > void *p; > > if ((err = dlerror())) { > error("earlier undetected dlerror: %s\n", err); > } > p = dlsym(handle, sym); > if ((err = dlerror())) { >

Hi Reid, > > if ((err = dlerror())) { > > error("earlier undetected dlerror: %s\n", err); > > } > > p = dlsym(handle, sym); > > if ((err = dlerror())) { > > error("dlsym failed: %s\n", err); > > } > > No, you're not missing anything. The correct way to check for errors > is with

Hi Ralph, On Fri, 2007-07-20 at 12:22 +0100, Ralph Corderoy wrote: > Hi Reid, > > > > if ((err = dlerror())) { > > > error("earlier undetected dlerror: %s\n", err); > > > } > > > p = dlsym(handle, sym); > > > if ((err = dlerror())) { > > > error("dlsym failed: %s\n", err); > >

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

On Fri, 20 Jul 2007, Ralph Corderoy wrote: > I could be missing something, but shouldn't the use of dlsym() be > The authors of dlsym() realised the return value was overloaded AFAICS. Yep, patches welcome :) -Chris -- http://nondot.org/sabre/ http://llvm.org/

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

Greetings list, I am working on a project on which we wish to use Speex with Google Automatic Speech Recognition (ASR) to transcribe Speex audio being sent on to Google ASR service and return us the text of the spoken audio in the Speex audio stream. However, Google ASR's Speex support requires the off-standard Speex-with-header-byte format, and my group cannot find any worthwhile

Greetings list, I am working on a project on which we wish to use Speex with Google Automatic Speech Recognition (ASR) to transcribe Speex audio being sent on to Google ASR service and return us the text of the spoken audio in the Speex audio stream. However, Google ASR's Speex support requires the off-standard Speex-with-header-byte format, and my group cannot find any worthwhile

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 this is likely just an accident rather than on purpose. There's totally room for that to happen, but it'll be the job of the client and not MCJIT itself. Basically whomever should call dlopen if they want to and it's the problem of the client application (which could be lli as the canonical mcjit example) to link in the correct bits. Make sense? If you can see a use case in

> 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

That seems to work, thanks! The specific code I ended up with to call int64_t print(int64_t) looks like: auto f = builder.CreateIntToPtr( ConstantInt::get(builder.getInt64Ty(), uintptr_t(print)), PointerType::getUnqual(FunctionType::get( builder.getInt64Ty(), {builder.getInt64Ty()}, false))); return builder.CreateCall(f, args); On Mon, Mar

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

Right, but when you say link time, the JIT compiler I'm writing works the way openJDK or v8 do, it reads a script, JIT compiles it into memory and runs the code in memory without ever writing anything to disk (an option for ahead of time compilation may come later, but that will be a while down the road), so we might be doing different things? On Tue, Mar 29, 2016 at 2:59 AM, Philip Reames