Nick Lewycky
2009-Nov-18 05:40 UTC
[LLVMdev] lli -force-interpreter complains about external function
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.50Only because the optimizer saw sin(constant) and folded it away. The entire program became 'print constant string'. There is certainly a bug calling sinf() from the interpreter but I don't know what it is yet.> The pthread problem remains after llvm-ld: > > $ lli -force-interpreter=true -load=/lib/libpthread.so.0 phello.llvm.bc > 0 lli 0x08796bf8 > Segmentation faultI don't expect this to work at all. Unlike the JIT, I don't know of any work having been done to make the interpreter thread-safe. By the way, the interpreter can't support many more things, such as qsort() or any method which expects to call a function pointer. Is there a reason you need to use the interpreter? It's been largely undermaintained because it's pretty much useless when you've got a working JIT. Nick> For those who are getting "invalid ELF header" error when calling > llvm-ld with -lpthread, > please change the load module from /usr/lib/pthread.a to > /lib/libpthread.so.0. > > Thanks > Xu > > On Wed, Nov 18, 2009 at 12:02 AM, Xu Yang <yangx2000 at gmail.com > <mailto:yangx2000 at gmail.com>> wrote: > > 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 in the interpreter? > ii) how do I specify the dynamic library (where the external > function is implemented), when I call the interpreter? > > Thanks > Xu > > hellosin.c > ======================> #include <stdio.h> > #include <math.h> > > > int main(int argc, char** argv){ > float f = sinf(0.5235988f); > printf("hello sin: %10.2f\n", f); > return 0; > } > =======================> $ llvm-gcc -o hellosin.bc -emit-llvm -c hellosin.c > $ lli -force-interpreter=true hellosin.bc > hello sin: 0.00 > $ lli hellosin.bc > hello sin: 0.50 > > phello.c > =======================> #include <pthread.h> > #include <stdio.h> > #define NUM_THREADS 4 > > void *PrintHello(void *threadid) > { > long tid; > tid = (long)threadid; > printf("Hello from %ld.\n", tid); > pthread_exit(NULL); > } > > int main (int argc, char *argv[]) > { > pthread_t threads[NUM_THREADS]; > int ret; > long t; > for(t=0; t<NUM_THREADS; t++){ > #ifdef DEBUG > printf("creating thread %ld\n", t); > #endif > ret = pthread_create(&threads[t], NULL, PrintHello, (void *)t); > if (ret){ > printf("pthread_create ERROR: %d\n", ret); > return(-1); > } > } > pthread_exit(NULL); > } > =======================> $ llvm-gcc -o phello.bc -emit-llvm -c phello.c > $ lli -force-interpreter=true phello.bc > 0 lli 0x08796bf8 > Segmentation fault > $ lli phello.bc > Hello from 0. > Hello from 1. > Hello from 2. > Hello from 3. > > > On Tue, Nov 17, 2009 at 2:52 AM, Nick Lewycky <nicholas at mxc.ca > <mailto:nicholas at mxc.ca>> wrote: > > Timo Juhani Lindfors wrote: > > Nick Lewycky<nicholas at mxc.ca <mailto: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 > was a bug and reported it at > http://llvm.org/bugs/show_bug.cgi?id=5466) how about making > lli inform > the user that LLVM was built without FFI support? > > > 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. > > Nick > > >
Nick Lewycky
2009-Nov-18 05:43 UTC
[LLVMdev] lli -force-interpreter complains about external function
Nick Lewycky wrote:> 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 > calling sinf() from the interpreter but I don't know what it is yet.Fixed in r89198. Nick
Xu Yang
2009-Nov-18 06:03 UTC
[LLVMdev] lli -force-interpreter complains about 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 wish to know if there are any other threads accessing the variables in the critical section without first acquiring a lock. I can do it with native code, but I will have to insert memory check function calls before all memory access instructions (load/store...), which is painful. But if I can run the program in interpreter, I can intercept the load and store instruction in the interpreter, and do the memory check there, which is completely transparent to the user program. Do you have any suggestions on how LLVM may help in this case? Thanks Xu On Wed, Nov 18, 2009 at 12:40 AM, Nick Lewycky <nicholas at mxc.ca> wrote:> 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 calling > sinf() from the interpreter but I don't know what it is yet. > > > The pthread problem remains after llvm-ld: >> >> $ lli -force-interpreter=true -load=/lib/libpthread.so.0 phello.llvm.bc >> 0 lli 0x08796bf8 >> Segmentation fault >> > > I don't expect this to work at all. Unlike the JIT, I don't know of any > work having been done to make the interpreter thread-safe. > > By the way, the interpreter can't support many more things, such as qsort() > or any method which expects to call a function pointer. Is there a reason > you need to use the interpreter? It's been largely undermaintained because > it's pretty much useless when you've got a working JIT. > > Nick > > For those who are getting "invalid ELF header" error when calling >> llvm-ld with -lpthread, >> please change the load module from /usr/lib/pthread.a to >> /lib/libpthread.so.0. >> >> Thanks >> Xu >> >> On Wed, Nov 18, 2009 at 12:02 AM, Xu Yang <yangx2000 at gmail.com >> <mailto:yangx2000 at gmail.com>> wrote: >> >> 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 in the interpreter? >> ii) how do I specify the dynamic library (where the external >> function is implemented), when I call the interpreter? >> >> Thanks >> Xu >> >> hellosin.c >> ======================>> #include <stdio.h> >> #include <math.h> >> >> >> int main(int argc, char** argv){ >> float f = sinf(0.5235988f); >> printf("hello sin: %10.2f\n", f); >> return 0; >> } >> =======================>> $ llvm-gcc -o hellosin.bc -emit-llvm -c hellosin.c >> $ lli -force-interpreter=true hellosin.bc >> hello sin: 0.00 >> $ lli hellosin.bc >> hello sin: 0.50 >> >> phello.c >> =======================>> #include <pthread.h> >> #include <stdio.h> >> #define NUM_THREADS 4 >> >> void *PrintHello(void *threadid) >> { >> long tid; >> tid = (long)threadid; >> printf("Hello from %ld.\n", tid); >> pthread_exit(NULL); >> } >> >> int main (int argc, char *argv[]) >> { >> pthread_t threads[NUM_THREADS]; >> int ret; >> long t; >> for(t=0; t<NUM_THREADS; t++){ >> #ifdef DEBUG >> printf("creating thread %ld\n", t); >> #endif >> ret = pthread_create(&threads[t], NULL, PrintHello, (void *)t); >> if (ret){ >> printf("pthread_create ERROR: %d\n", ret); >> return(-1); >> } >> } >> pthread_exit(NULL); >> } >> =======================>> $ llvm-gcc -o phello.bc -emit-llvm -c phello.c >> $ lli -force-interpreter=true phello.bc >> 0 lli 0x08796bf8 >> Segmentation fault >> $ lli phello.bc >> Hello from 0. >> Hello from 1. >> Hello from 2. >> Hello from 3. >> >> >> On Tue, Nov 17, 2009 at 2:52 AM, Nick Lewycky <nicholas at mxc.ca >> <mailto:nicholas at mxc.ca>> wrote: >> >> Timo Juhani Lindfors wrote: >> >> Nick Lewycky<nicholas at mxc.ca <mailto: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 >> was a bug and reported it at >> http://llvm.org/bugs/show_bug.cgi?id=5466) how about making >> lli inform >> the user that LLVM was built without FFI support? >> >> >> 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. >> >> Nick >> >> >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091118/f2f4f7ab/attachment.html>
Jeffrey Yasskin
2009-Nov-18 06:12 UTC
[LLVMdev] lli -force-interpreter complains about external function
Have you looked at http://code.google.com/p/data-race-test/wiki/ThreadSanitizer or http://valgrind.org/docs/manual/hg-manual.html? They have the advantage of having already been debugged. On Tue, Nov 17, 2009 at 10:03 PM, Xu Yang <yangx2000 at gmail.com> wrote:> 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 wish to know if there are any > other threads accessing the variables in the critical section without first > acquiring a lock. I can do it with native code, but I will have to insert > memory check function calls before all memory access instructions > (load/store...), which is painful. But if I can run the program in > interpreter, I can intercept the load and store instruction in the > interpreter, and do the memory check there, which is completely transparent > to the user program. > Do you have any suggestions on how LLVM may help in this case? > > Thanks > Xu > > On Wed, Nov 18, 2009 at 12:40 AM, Nick Lewycky <nicholas at mxc.ca> wrote: >> >> 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 >> calling sinf() from the interpreter but I don't know what it is yet. >> >>> The pthread problem remains after llvm-ld: >>> >>> $ lli -force-interpreter=true -load=/lib/libpthread.so.0 phello.llvm.bc >>> 0 lli 0x08796bf8 >>> Segmentation fault >> >> I don't expect this to work at all. Unlike the JIT, I don't know of any >> work having been done to make the interpreter thread-safe. >> >> By the way, the interpreter can't support many more things, such as >> qsort() or any method which expects to call a function pointer. Is there a >> reason you need to use the interpreter? It's been largely undermaintained >> because it's pretty much useless when you've got a working JIT. >> >> Nick >> >>> For those who are getting "invalid ELF header" error when calling >>> llvm-ld with -lpthread, >>> please change the load module from /usr/lib/pthread.a to >>> /lib/libpthread.so.0. >>> >>> Thanks >>> Xu >>> >>> On Wed, Nov 18, 2009 at 12:02 AM, Xu Yang <yangx2000 at gmail.com >>> <mailto:yangx2000 at gmail.com>> wrote: >>> >>> 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 in the interpreter? >>> ii) how do I specify the dynamic library (where the external >>> function is implemented), when I call the interpreter? >>> >>> Thanks >>> Xu >>> >>> hellosin.c >>> ======================>>> #include <stdio.h> >>> #include <math.h> >>> >>> >>> int main(int argc, char** argv){ >>> float f = sinf(0.5235988f); >>> printf("hello sin: %10.2f\n", f); >>> return 0; >>> } >>> =======================>>> $ llvm-gcc -o hellosin.bc -emit-llvm -c hellosin.c >>> $ lli -force-interpreter=true hellosin.bc >>> hello sin: 0.00 >>> $ lli hellosin.bc >>> hello sin: 0.50 >>> >>> phello.c >>> =======================>>> #include <pthread.h> >>> #include <stdio.h> >>> #define NUM_THREADS 4 >>> >>> void *PrintHello(void *threadid) >>> { >>> long tid; >>> tid = (long)threadid; >>> printf("Hello from %ld.\n", tid); >>> pthread_exit(NULL); >>> } >>> >>> int main (int argc, char *argv[]) >>> { >>> pthread_t threads[NUM_THREADS]; >>> int ret; >>> long t; >>> for(t=0; t<NUM_THREADS; t++){ >>> #ifdef DEBUG >>> printf("creating thread %ld\n", t); >>> #endif >>> ret = pthread_create(&threads[t], NULL, PrintHello, (void *)t); >>> if (ret){ >>> printf("pthread_create ERROR: %d\n", ret); >>> return(-1); >>> } >>> } >>> pthread_exit(NULL); >>> } >>> =======================>>> $ llvm-gcc -o phello.bc -emit-llvm -c phello.c >>> $ lli -force-interpreter=true phello.bc >>> 0 lli 0x08796bf8 >>> Segmentation fault >>> $ lli phello.bc >>> Hello from 0. >>> Hello from 1. >>> Hello from 2. >>> Hello from 3. >>> >>> >>> On Tue, Nov 17, 2009 at 2:52 AM, Nick Lewycky <nicholas at mxc.ca >>> <mailto:nicholas at mxc.ca>> wrote: >>> >>> Timo Juhani Lindfors wrote: >>> >>> Nick Lewycky<nicholas at mxc.ca <mailto: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 >>> was a bug and reported it at >>> http://llvm.org/bugs/show_bug.cgi?id=5466) how about making >>> lli inform >>> the user that LLVM was built without FFI support? >>> >>> >>> 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. >>> >>> Nick >>> >>> >>> >> > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >
Apparently Analagous Threads
- [LLVMdev] lli -force-interpreter complains about external function
- [LLVMdev] lli -force-interpreter complains about external function
- [LLVMdev] lli -force-interpreter complains about external function
- [LLVMdev] lli -force-interpreter complains about external function
- [LLVMdev] lli -force-interpreter complains about external function