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>