llvm dev - Oct 2008 - [LLVMdev] Debugging lli using bugpoint

Hi,

I have a program that runs when statically compiled using llc and gcc but
crashes with a segmentation fault when run with lli. I am trying to debug it
with bugpoint and the initial part of bugpoint seems to be suggesting that I
am somehow missing the linking with the libraries having dlsym/dlopen
although I am passing it to lli :

*$ bugpoint -run-jit $HOME/gap/gap4r4/bin/i686-pc-linux-gnu-llvm-gcc/gap.bc
--tool-args -load=/usr/lib/libm.so -load=/usr/lib/libdl.so --args  -l
$HOME/gap/gap4r4/ -m 1024M*

Read input file      :
'/home/pprabhu/gap/gap4r4/bin/i686-pc-linux-gnu-llvm-gcc/gap.bc'
*** All input ok
Initializing execution environment: Found lli:
/home/pprabhu/llvm/llvm-install/bin/lli
Running the code generator to test for a crash:
Generating reference output from raw program: <cbe><gcc>
Error running tool:
 /usr/bin/gcc -x c -fno-strict-aliasing bugpoint-test-program.bc.cbe.c -x
none -o bugpoint-test-program.bc.cbe.c.gcc.exe -lm -O2 -Wl,-R.
bugpoint-test-program.bc.cbe.c:5149: warning: conflicting types for built-in
function 'malloc'
bugpoint-test-program.bc.cbe.c: In function 'ExecProccall0args':
bugpoint-test-program.bc.cbe.c:401008: warning: passing argument 1 of
'longjmp' from incompatible pointer type

....


*/tmp/cc08IpX8.o: In function `SyLoadModule':
bugpoint-test-program.bc.cbe.c:(.text+0x25705): undefined reference to
`dlopen'
bugpoint-test-program.bc.cbe.c:(.text+0x25719): undefined reference to
`dlsym'
/tmp/cc08IpX8.o: In function `SyFindOrLinkGapRootFile':
bugpoint-test-program.bc.cbe.c:(.text+0x6b951): undefined reference to
`dlopen'
bugpoint-test-program.bc.cbe.c:(.text+0x6b965): undefined reference to
`dlsym'
/tmp/cc08IpX8.o: In function `FuncLOAD_DYN':
bugpoint-test-program.bc.cbe.c:(.text+0x12a92d): undefined reference to
`dlopen'
bugpoint-test-program.bc.cbe.c:(.text+0x12a945): undefined reference to
`dlsym'
/tmp/cc08IpX8.o: In function `LoadWorkspace':
bugpoint-test-program.bc.cbe.c:(.text+0x14487a): undefined reference to
`dlopen'
bugpoint-test-program.bc.cbe.c:(.text+0x144892): undefined reference to
`dlsym'
collect2: ld returned 1 exit status*

*** Debugging code generator crash!

Checking to see if we can delete global inits:
 - Removing all global inits hides problem!

*** Attempting to reduce the number of global variables in the testcase
Checking for crash with only these global variables:  Revision_ariths_c
ZeroFuncs ZeroMutFuncs AInvFuncs AInvMutFuncs OneFuncs OneMutFuncs InvFuncs
InvMutFuncs EqFuncs... <5919 total>:

*** Attempting to reduce the number of functions in the testcase
Checking for crash with only these functions:  InstallZeroObject
VerboseZeroObject ZeroObject FuncZERO InstallZeroMutObject
VerboseZeroMutObject ZeroMutObject FuncZERO_MUT InstallAinvObject
VerboseAInvObject... <2883 total>:
Checking for crash with only these blocks: entry entry bb bb2 entry bb bb2
entry bb1 bb2... <77209 total>:



Is there something that I missing here (like some more parameters to lli or
to bugpoint) because the program seems to run fine when compiled with llc.

Thanks for your time.

- Prakash
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20081028/804409c5/attachment.html>

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

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>