search for: codegen1

...inux distros How can I fix this? When I try to construct a function which will call "get5" it will fail on OS X, too. I have attached the whole .cpp file containing the complete code. It's adapted from the JIT example in the LLVM source distribution. I compile it using g++ -c codegen1.cpp -o codegen1.o -D__STDC_LIMIT_MACROS g++ -o codegen1 -L${LLVM_LIB_DIR} codegen1.o ${LLVM_LIB_DIR}/ LLVMPowerPC.o -lLLVMSelectionDAG ${LLVM_LIB_DIR}/LLVMInterpreter.o $ {LLVM_LIB_DIR}/LLVMJIT.o -lLLVMCodeGen -lLLVMScalarOpts - lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis ${LLVM_LIB_DIR}/ LLVM...

...> > When I try to construct a function which will call "get5" it will > fail on OS X, too. I have attached the whole .cpp file containing > the complete code. It's adapted from the JIT example in the LLVM > source distribution. I compile it using > > g++ -c codegen1.cpp -o codegen1.o -D__STDC_LIMIT_MACROS > g++ -o codegen1 -L${LLVM_LIB_DIR} codegen1.o ${LLVM_LIB_DIR}/ > LLVMPowerPC.o -lLLVMSelectionDAG ${LLVM_LIB_DIR}/LLVMInterpreter.o $ > {LLVM_LIB_DIR}/LLVMJIT.o -lLLVMCodeGen -lLLVMScalarOpts - > lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis ${...

...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 codegen1" I realized that "get5" was a C+ > + function whose name was mangled to "__Z4get5v". Surrounding it by > extern "C" helped a lot :) Now the function is found by the JIT and I > can call it using EE->runFunction als well as using a CallInst. > >&g...

...y, > 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 codegen1" I realized that "get5" was a C+ + function whose name was mangled to "__Z4get5v". Surrounding it by extern "C" helped a lot :) Now the function is found by the JIT and I can call it using EE->runFunction als well as using a CallInst. > Does this work?...

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 stub)? > > Yes. I create a Function with matching signature,

...t;> 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 codegen1" I realized that "get5" was a C+ >> + function whose name was mangled to "__Z4get5v". Surrounding it by >> extern "C" helped a lot :) Now the function is found by the JIT and I >> can call it using EE->runFunction als well as using a CallInst....

...xe 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 -------------- A non-text attachment was scrubbed... Name: codegen1.cpp Type: application/octet-stream Size: 4065 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070627/54390960/attachment.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: foo.c Type: application/octet-stream Size: 2...