[LLVMdev] Debugging lli using bugpoint

[Prakash Prabhu]

Hi Eli,

Thanks for the reply. I tried with -Xlinker="-ldl ". However it does not
seem to make a difference. It seems that when bugpoint is run with
--run-jit, the linker args are not passed to gcc  (from
tools/bugpoint/ExecutionDriver.cpp) :

if (InterpreterSel == RunLLC || InterpreterSel == RunCBE ||
      InterpreterSel == CBE_bug || InterpreterSel == LLC_Safe)

    RetVal = AI->ExecuteProgram(BitcodeFile, InputArgv, InputFile,
                                OutputFile, AdditionalLinkerArgs,
SharedObjs,
                                Timeout, MemoryLimit);

  else


    RetVal = AI->ExecuteProgram(BitcodeFile, InputArgv, InputFile,
                                OutputFile, std::vector<std::string>(),
                                SharedObjs, Timeout, MemoryLimit);


I tried the following after this:

(1) Firstly instead of running Gap (
http://www.gap-system.org/Download/UNIXInst.html), I am now trying to run
python with lli (http://www.python.org/download/releases/2.5.2/). I managed
to compile python.bc and here again I face the same problem:

llc and gcc can get python.exe to run (which is great :)!) :

$ llc -f python.bc
$ gcc -o python.exe python.s -ldl -lutil -lm -lrt
$ ./python.exe
Python 2.5.2 (r252:60911, Oct 31 2008, 14:41:11)
[GCC 4.2.1 (Based on Apple Inc. build 5623) (LLVM build)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>

however, when I try to run python.bc using lli it crashes with a
segmentation fault:

$ lli -load=/usr/lib/libdl.so -load=/usr/lib/libutil.so
-load=/usr/lib/libm.so -load=/usr/lib/librt.so python.bc

When i try it with gdb, it seems that the crash is somewhere inside python
code (since bt only shows ?? ).  Before the crash, I could see that the
memory consumption(VM) reaches somewhere near 80% of my 2GB RAM (seen via
top, and that too a sudden increase from around when it was previously
occupying around 2-3% of VM). I tried to run this on a 64-bit machine which
has 8GB RAM and still have the same issue wrt memory.

(2) Finally I wrote a pass (and loaded it through opt) to instrument each
function's (in python code ) entry and exit and then ran the instrumented
program with both [llc ; gcc] combination and lli. In the lli version a
single method (subtype_traverse) is recursively called (about 2 million
times) until the program runs out of memory while the statically compiled
code (llc + gcc) calls this method (I am comparing the calls in the same
context in both cases) only once:

python with llc + gcc :
...
(tupletraverse (visit_decref (type_is_gc)))
(subtype_traverse (visit_decref (type_is_gc))
(type_traverse (visit_decref) (visit_decref) ...

python with lli:

(tupletraverse (visit_decref (type_is_gc)))
(subtype_traverse (visit_decref (type_is_gc)) (subtype_traverse
(visit_decref (type_is_gc))(subtype_traverse (visit_decref (type_is_gc))
..... about 2 million times

Looking at the code (Objects/typeobject.c:
http://google.com/codesearch?hl=en&q=show:VK_wUSuAZto:jHKC99mjNVM:4z02hQcYQRY&sa=N&ct=rd&cs_p=http://gentoo.osuosl.org/distfiles/Python-2.5.tar.bz2&cs_f=Python-2.5/Objects/typeobject.c
)

 it seems the last call (through a function pointer) in subtype_traverse
results in this never-ending recursive call.

Has anyone tried compiling python to bit code and running it the LLVM JIT
before ?

Thanks for your time.

- Prakash





On Tue, Oct 28, 2008 at 3:02 PM, Eli Friedman <eli.friedman at gmail.com>wrote:

> On Tue, Oct 28, 2008 at 12:17 PM, Prakash Prabhu
> <prakash.prabhu at gmail.com> wrote:
> > Generating reference output from raw program: <cbe><gcc>
> > Error running tool:
> [snip]
> > /tmp/cc08IpX8.o: In function `SyLoadModule':
> > bugpoint-test-program.bc.cbe.c:(.text+0x25705): undefined reference to
> > `dlopen'
> [snip]
>
> This is saying that compilation with CBE is failing.  Try something
> like -Xlinker -ldl?
>
> -Eli
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081102/54161ee7/attachment.html>