similar to: [LLVMdev] lli -force-interpreter complains about external function

Xu Yang wrote: > Hi: > > When I try to execute lli -force-interpreter=true hello.bc, it gave the > following error: > > LLVM ERROR: Tried to execute an unknown external function: i32 (i8*)* puts > > I think the error is because C library is not being linked with the byte > code, but I was not able to find any helpful instruction in lli's document. > > Can you

I am writing a transformation that needs to add a call to a function F() at the beginning of main() with the addresses of argc and argv as parameters to F(). However, the bytecode file I'm transforming has not allocated space on the stack for argc and argv. So, I developed my transformation to change main() from: ----- int main(int %argc, sbyte** %argv){ entry: ... // some use of

After looking at this problem longer, I believe that there is something wrong with the disassembler. When I run my transformation and then disassemble the output, I get bytecode that looks like: ----- int %main(int %argc, sbyte** %argv) { entry: alloca int ; <int*>:0 [#uses=3] alloca sbyte** ; <sbyte***>:0 [#uses=3] store int %argc,

Hi Nick: The first problem have been solved by calling llvm-ld: $ llvm-ld -o hellosin.llvm hellosin.bc -lm $ lli -force-interpreter=true -load=/usr/lib/libm.so hellosin.llvm.bc hello sin: 0.50 The pthread problem remains after llvm-ld: $ lli -force-interpreter=true -load=/lib/libpthread.so.0 phello.llvm.bc 0 lli 0x08796bf8 Segmentation fault For those who are getting "invalid

Hi Nick: Thanks for pointing me to libffi. Recompile LLVM with libffi does solve the problem of printf. But it still has other problems: 1) sinf() returns 0 in the interpreter, but returns correct value in JIT (see hellosin.c) 2) calling pthread_create cause lli to crash in the interpreter mode, but no problem in JIT (see phello.c). My questions are: i) can I call any arbitrary external function

Hi Nick: Thanks for the response. You are right about sinf. I changed the constant to sscanf(argv[1], ...), and it gave me back 0 again. I also compared the disassembled code, and saw it was indeed the case. The primary reason I use interpreter is because I wish to do runtime checking on memory access pattern in multithreaded C programs. for example, if thread one is in the critical section, I

Xu Yang wrote: > Hi Nick: > > The first problem have been solved by calling llvm-ld: > > $ llvm-ld -o hellosin.llvm hellosin.bc -lm > $ lli -force-interpreter=true -load=/usr/lib/libm.so hellosin.llvm.bc > hello sin: 0.50 Only because the optimizer saw sin(constant) and folded it away. The entire program became 'print constant string'. There is certainly a bug

Hi, 1. Does the alignment of the pointer returned by an AllocaInst depend on the instructions before it in the basic block? The 1st snippet below aligns 'a' correctly, while the 2nd one doesnt. (the method handle_args, only prints out the values of arguments, and returns argv unchanged). define i32 @main(i32 %argc, i8** %argv) nounwind { entry: %argc_addr = alloca i32

On 25 Dec 2007, at 03:29, Gordon Henriksen wrote: > Hi Jo, > > On 2007-12-24, at 14:43, Joachim Durchholz wrote: > >> I'm in a very preliminary phase of a language project which requires >> some specific optimizations to be reasonably efficient. >> >> LLVM already looks very good; I'd just like to know whether I can >> push these optimizations

Nick Lewycky <nicholas at mxc.ca> writes: > The interpreter uses libffi to make external function calls. However, it > needs to be detected at LLVM's compile time. If you're using the > released packages, we disabled that because we were worried about users > who don't have libffi installed. This seems to be quite a common problem (I too hit it once, thought it

Timo Juhani Lindfors wrote: > Nick Lewycky<nicholas at mxc.ca> writes: >> The interpreter uses libffi to make external function calls. However, it >> needs to be detected at LLVM's compile time. If you're using the >> released packages, we disabled that because we were worried about users >> who don't have libffi installed. > > This seems to be

hi, Dale Johannesen wrote: > On Oct 19, 2007, at 7:23 AM, Dietmar Ebner wrote: >> i'm trying to make some experiments with the ARM backend (llvm 2.1) >> and >> therefore built an arm-softfloat-linux-gnu toolchain on x86_64 linux. >> >> however, the llvm-gcc frontend seems to cause troubles with single >> precision floating point values, i.e., they are

Hi LLVM and GCC developers, My sincere thanks will goto: * Duncan, the core developer of llvm-gcc and dragonegg http://llvm.org/devmtg/2009-10/Sands_LLVMGCCPlugin.pdf * David, the innovator and developer of GCC https://dmalcolm.fedorapeople.org/gcc/global-state/requirements.html and others who give me kind response for teaching me patiently and carefully about how to migrate GCC v4.8.x to

Hello everyone, I'm trying to run a LLVM-Bytecode-file in the interpreter (lli --force-interpreter), but i'm getting the following error-message: LLVM ERROR: Tried to execute an unknown external function: i8* (i32)* malloc My program is calling malloc. If I omit --force-interpreter everything runs as expected. Compiling to Assembler also works without problems. I have compiled LLVM with

On Dec 25, 2007, at 9:07 AM, Arnold Schwaighofer wrote: > On 25 Dec 2007, at 03:29, Gordon Henriksen wrote: > >> Hi Jo, >> >> On 2007-12-24, at 14:43, Joachim Durchholz wrote: >> >>> I'm in a very preliminary phase of a language project which requires >>> some specific optimizations to be reasonably efficient. >>> >>> LLVM

On Oct 19, 2007, at 7:23 AM, Dietmar Ebner wrote: > hi, > > i'm trying to make some experiments with the ARM backend (llvm 2.1) > and > therefore built an arm-softfloat-linux-gnu toolchain on x86_64 linux. > > however, the llvm-gcc frontend seems to cause troubles with single > precision floating point values, i.e., they are not converted > correctly > to the

Nick Lewycky <nicholas at mxc.ca> writes: > Thanks for the reminder. I recall looking at the patch but I didn't > apply it at the time because I couldn't figure out why the code above > it used errs() in one case and llvm_report_error in another. What was the reason? (I think I too wondered that.)

Hi Jo, On 2007-12-24, at 14:43, Joachim Durchholz wrote: > I'm in a very preliminary phase of a language project which requires > some specific optimizations to be reasonably efficient. > > LLVM already looks very good; I'd just like to know whether I can > push these optimizations through LLVM to the JIT phase (which, as > far as I understand the docs, is a

hi, i've got some more things to note. first, the issue is not related to x86_64 being the host machine - it also happens on i686/linux. next, i think (one of) the problem(s) is the use of [HOST_]WORDS_BIG_ENDIAN instead of [HOST_]FLOAT_WORDS_BIG_ENDIAN in llvm-convert.cpp (see patch below). this fixes single precision floating point but breaks double precision. for

hi, i'm trying to make some experiments with the ARM backend (llvm 2.1) and therefore built an arm-softfloat-linux-gnu toolchain on x86_64 linux. however, the llvm-gcc frontend seems to cause troubles with single precision floating point values, i.e., they are not converted correctly to the particular target format (double precision works as expected). it seems the problem is related to