similar to: [LLVMdev] Function binding

Hi Gael, I tried converting to your approach but I had some issues making sure that all symbols accessed by the jit modules have entries in the dynamic symbol table. To be specific, my current approach is to use MCJIT (using an objectcache) to JIT the runtime module and then let MCJIT handle linking any references from the jit'd modules; I just experimented with what I think you're doing,

Sorry for the top posting, it's the gmail app behavior. It didn't mention the other aspects because they are not a problem. The only "problem" is the package depency. Cordially Le 11 nov. 2014 19:03, "Pino Toscano" <ptoscano@redhat.com> a écrit : > > Hi, > > (please do not top-reply...) > > On Tuesday 11 November 2014 18:32:10 Mathieu

Hi Vania, If I understood correctly, you have an executable, which is JITing code that has dependencies on the symbols of entire executable. In case dlsym cannot find this symbol, try to link your executable with -rdynamic (gcc) or --export-dynamic (ld): -rdynamic Pass the flag -export-dynamic to the ELF linker, on targets that support it. This instructs the linker

What I was suggesting, is to let the user manage depencies himself. This is what slackware users are used to do anyway. It means that we should be able to provide an exhaustive list of needed packages on the command line. As the semantic differ from the usual treatment of the PACKAGES arguments of supermin --prepare, this could be managed by a new option implying "do not search or install

Thanks for the pointers. Am I correct in assuming that putting the precompiled bitcode into a second module and linking (or using the object caches) would result in ordinary function calls, but would not be able to inline the functions? -- lg On Jan 21, 2014, at 11:55 AM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > I would say that the incompatibility is by design. Not

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

Hello LLVM developers, I am developing a small project using LLVM. The objective is to provide dynamic loading via JIT compilation of C++ code contained in a (TS) module. For this reason, I would like to return an explicitly raw void pointer (resembling libdl's `void *dlsym(void *, char const *);` as closely as possible) to the compiled result. The MCJIT class offers the most convenient API

Hi all, There are symbols in libgcc (and compiler-rt) that JIT-compiled modules may need. These are currently linked correctly because lli and friends are linked against libgcc_s.so (i.e. shared library version of libgcc, so dlopen/dlsym works). However if a consumer links statically, dlsym won't find all compiler required functions (only the ones that were required by the JIT-compiler

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, We are new in LLVM... We want to execute JIT'ed code that links to functions inside our application For example, the JIT has compiled code like extern void open_device(Device * dev); int foo_bar() { Device dev; ... ; open_device(&dev); ...;} / /where open_device() is a function in our own code, that has initialized and called the ExecutionEngine. Of course when running we get the

FYI .. if you want to see how this works, check out lib/System/DynamicLibrary.cpp and platform versions of it. Reid. On Sun, 2004-11-28 at 10:03, Reid Spencer wrote: > Well, one of these days we'll be using libltdl (libtool's dynamic > library support) to make the interface to dynamic libraries consistent, > somewhat portable, and to get rid of system specific differences like

Hi, I was able to try this on linux again. Unfortunately it doesn't work at all (neither using runFunction nor a CallInst). It simply says function called get5 not known. Calling printf the same way works, though. On linux the function is exported as "get5" from the executable while it is called "_get5" on OS X. I could not spot any other differences.. any

On Tue, Mar 12, 2013 at 9:19 AM, Renato Golin <renato.golin at linaro.org>wrote: > On 12 March 2013 15:28, Hal Finkel <hfinkel at anl.gov> wrote: > >> Can't we just paste in a RNG so that we'll get the same output on all >> systems (and can still use the reference output)? >> > > We can, though other tests suffer from the same issue. Would be good

Hi I tried to install the kernel Red Hat 5.3 x86_64 (2.6.18-128.el5.x86_64) with the command: rpm -Uvh kernel-2.6.18-128.el5.x86_64.rpm but there is problem with dependecy: ecryptfs-util < 44. How to solve problems with depencies when installing a beta kernel? I'm trying this kernel to see if I get CentOS working with the wireless iw4965. I tried the drivers from Intel, but the

Turns out it wasn't using the JIT. It was running the interpreter. The X86 stuff wasn't being linked in. Alas, once I "fixed" that, it stopped working. The JIT couldn't resolve the symbol "printf" and failed. But the interpreter could resolve it. Misha Brukman wrote: >On Wed, Dec 22, 2004 at 08:48:19PM -0800, Jeff Cohen wrote: > > >>I

> As far as I know, ObjectFile is either COFF, ELF or MachO format, > statically compiled. But the pass manager for applying optimisation > passes works only on llvm-ir. I would not need to apply optimisations on the parts of the program in the object file. These are meant to be optimised beforehand. The only parts I want to run passes on are specific function that I know

The DynamicLibrary.cpp code is written and I believe it to be complete, but it hasn't been tested much (at all). llvm-ld uses it to load its plug-in optimization module. The implementation will use ltdl library if its available, otherwise it tries to use dlopen/dlsym if they are available, otherwise you get a compile time warning and (void*)0 if you try to look up a symbol. I'm not sure

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

Misha, The "equivalent of dlsym" should be working just fine. Its called ltdl (libtool dynamic library) and is part of lib/System. Its interface is the DynamicLibrary class. The interpreter has already been modified to use this facility. So, if this is broken on windows, I'd like to know how, or why. Jeff, can you provide a test case that we can use to reproduce this problem?

On Sun, 28 Nov 2004, Reid Spencer wrote: > FYI .. if you want to see how this works, check out > lib/System/DynamicLibrary.cpp and platform versions of it. Is it an option to use this interface now? How does libtool implement dlsym on darwin if not through the obvious interface? Can we just use whatever it uses? -Chris > On Sun, 2004-11-28 at 10:03, Reid Spencer wrote: > >