search for: rehder

...tion 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 thoughts? greetings, Jan On 12. Jun 2007, at 23:08, Jan Rehders wrote: > Hi, > >> Okay. If the function exists in your application's address space >> already, >> just name the LLVM function the same name as the native function >> and the >> JIT should find it an do the right thing. This is how it finds >> printf...

On Tue, 12 Jun 2007, Jan Rehders wrote: >> Jan, how are you doing this? Are you creating an external LLVM >> Function object named "get5", then using EE::addGlobalMapping? If >> 'get5' exists in the address space, why not just let the JIT resolve it >> (which will then create the stu...

...C.o -lLLVMSelectionDAG ${LLVM_LIB_DIR}/LLVMInterpreter.o $ {LLVM_LIB_DIR}/LLVMJIT.o -lLLVMCodeGen -lLLVMScalarOpts - lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis ${LLVM_LIB_DIR}/ LLVMExecutionEngine.o -lLLVMTarget -lLLVMCore -lLLVMSupport - lLLVMbzip2 -lLLVMSystem -lpthread -ldl greetings, Jan Rehders -------------- next part -------------- A non-text attachment was scrubbed... Name: codegen1.cpp Type: application/octet-stream Size: 5240 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070607/653399de/attachment.obj>

On 2007-10-02, at 10:46, Jan Rehders wrote: > where can I read more about this? I assume (hope) the lib provides > some kind of OCaml bindings? I could not find any trace of it in > the 2.1 release source so I guess it's currently SVN only? Jan, Here's a trivial example. $ cat metahelloworld.ml (* metahellowo...

On Dec 23, 2008, at 7:15 AM, Jan Rehders wrote: > Hi, > > when upgrading my compiler from LLVM 2.1 to 2.4 I stumbled upon a > change of behaviour in ParseAssemblyString. For an interactive > toplevel I am generating .ll source and feeding it into > ParseAssemblyString like this: Hi Jan, I don't think that there i...

On 11 Jun 2007, at 22:35, Jan Rehders wrote: > It's inside PPCJITInfo::relocate but unfortunately I could not figure > out anything from the source. It looks like it's calculating new > addresses for functions which does not make much sense for a native > function, at all On the PPC, unconditional branches are li...

Hi, > I know nothing about this, but the failed assertion suggests the PPC > code generator can't cope with a constant that's bigger than > expected at > that point. Have you taken a look at PPCJITInfo.cpp:382? It may shed > some light. It's inside PPCJITInfo::relocate but unfortunately I could not figure out anything from the source. It looks like it's

Hi, when upgrading my compiler from LLVM 2.1 to 2.4 I stumbled upon a change of behaviour in ParseAssemblyString. For an interactive toplevel I am generating .ll source and feeding it into ParseAssemblyString like this: Module* parsedModule = ParseAssemblyString( code, targetModule, &errorInfo ); where targetModule is the module I expect all the LLVM code to go. Until 2.1 the

Are you able make calls to well known external functions such as printf? As far as I known, this capability is well tested on x86 / Linux. I am wondering if there is some name mangling issue? Evan On Jun 7, 2007, at 8:38 AM, Jan Rehders wrote: > Hello, > > can anyone help me calling native functions from LLVM-Bytecode > functions run in the JIT? > > I have a program which creates an LLVM execution engine and adds > modules and functions > to it on the fly. I need to call some native functions of my...

Jon, >> . Some interface to LLVM from OCaml >> >> What work has already been done on this and similar ideas? What is >> the >> easiest >> way to interface a front-end written in OCaml with an LLVM backend? I've written a compiler front end for a custom language in OCaml which features compilation and an interactive toplevel. Until now I am

On Mon, 11 Jun 2007, Jonas Maebe wrote: > On 11 Jun 2007, at 22:35, Jan Rehders wrote: >> It's inside PPCJITInfo::relocate but unfortunately I could not figure >> out anything from the source. It looks like it's calculating new >> addresses for functions which does not make much sense for a native >> function, at all > > On the PPC, uncon...

...AddressSDNode *G = dyn_cast<GlobalAddressSDNode>(Callee)) Callee = DAG.getTargetGlobalAddress(G->getGlobal(), Callee.getValueType()); This will force an indirect call, and won't use the jump-size limitation of the bl instruction. Let me know if this helps. Cheers, Nicolas Jan Rehders wrote: > Hi, > > attached is a small testcase I did. It builds two LLVM functions which > both call two native functions get5 and get6. The native functions are > in the exe and in the dll. On OS X it works like a charm. On Linux > none of the two functions can be called. >...

To build 64-bit libraries (i.e. 'file <library>' shows x86_64) try 'make EXTRA_OPTIONS=-m64" Either 32-bit or 64-bit libraries are able to generate code for either 32-bit or 64-bit, try -m32 or -m64 at runtime On Feb 9, 2009, at 4:16 PMPST, Jan Rehders wrote: > Hi, > > how do I compile LLVM for 64-bit on OS X? I want to get 64-bit > libraries which generate x86_64 to link them into a 64-bit > application. All my attempts ended up with either 32-bit libraries or > errors. My machine is an Intel Xeon quad core, 'sysctl >...

Hi, > Okay. If the function exists in your application's address space > already, > just name the LLVM function the same name as the native function > and the > JIT should find it an do the right thing. This is how it finds > printf and > a variety of other things. You don't need to call addGlobalMapping at > all. Looking at the output of "nm

...veBody, then reading the .ll file back in using ParseAssemblyString). I noticed that functions are represented as an llvalue which makes turning it into a Function* unsafe if I'm correct? greetings, Jan On 2. Okt 2007, at 19:51, Gordon Henriksen wrote: > On 2007-10-02, at 10:46, Jan Rehders wrote: > >> where can I read more about this? I assume (hope) the lib provides >> some kind of OCaml bindings? I could not find any trace of it in >> the 2.1 release source so I guess it's currently SVN only? > > Jan, > > Here's a trivial example. >...

Hi, where can I read more about this? I assume (hope) the lib provides some kind of OCaml bindings? I could not find any trace of it in the 2.1 release source so I guess it's currently SVN only? greetings, Jan On 2. Okt 2007, at 12:22, Gordon Henriksen wrote: > On 2007-10-02, at 03:19, Gordon Henriksen wrote: > >> On Oct 2, 2007, at 00:17, Bill Wendling wrote: >>

Hi, attached is a small testcase I did. It builds two LLVM functions which both call two native functions get5 and get6. The native functions are in the exe and in the dll. On OS X it works like a charm. On Linux none of the two functions can be called. Maybe someone can try them or have a look at it to see if there is something obviously wrong greetings, Jan -------------- next part

Hi, how do I compile LLVM for 64-bit on OS X? I want to get 64-bit libraries which generate x86_64 to link them into a 64-bit application. All my attempts ended up with either 32-bit libraries or errors. My machine is an Intel Xeon quad core, 'sysctl hw.cpu64bit_capable' returns 1 so I think the machine is fine. - './configure && make' yields 32-bit libraries and

Hi Jan, In gcc for Linux, you have the -rdynamic option that allows an executable to dlsym its symbols. Since llvm use dlsym to find the symbols, you could try with this option. That's what I did. And don't forget to use the C++ name if you compile with C++. Cheers, Nicolas Jan Rehders wrote: > 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...

On 2007-10-02, at 03:19, Gordon Henriksen wrote: > On Oct 2, 2007, at 00:17, Bill Wendling wrote: > >> I get this error duing a "make install": >> >> llvm[3]: Installing Debug /usr/local/lib/ocaml/libllvm.a >> install: /usr/local/lib/ocaml/libllvm.a: Permission denied >> make[3]: *** [install-a] Error 71 >> make[2]: *** [install] Error 1