[LLVMdev] lli -force-interpreter complains about external function

[Xu Yang]

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>