Displaying 6 results from an estimated 6 matches for "subtype_traverse".
2008 Nov 02
2
[LLVMdev] Debugging lli using bugpoint
...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)))
(subt...
2008 Nov 04
4
[LLVMdev] Debugging lli using bugpoint
...} else {
fprintf(stderr, "Bad!\n");
exit(1);
}
}
$ llvm-gcc -emit-llvm -o FPtrEqTest.bc -c FPtrEqTest.c
$ llc -f FPtrEqTest.bc
$ gcc -o FPtrEqTest FPtrEqTest.s
$ ./FPtrEqTest
OK!
$ lli FPtrEqTest.bc
Bad!
The above test case is just a smaller version of the one in Python's
subtype_traverse which also tests a function pointer and calls itself. It
seems the problem arises due comparison with the stub's address when a
comparison with the actual address of the compiled function is intended.
thanks,
Prakash
On Mon, Nov 3, 2008 at 2:07 AM, Evan Cheng <evan.cheng at apple.com> w...
2008 Nov 03
0
[LLVMdev] Debugging lli using bugpoint
...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 :
> ...
> (tupletra...
2008 Nov 11
0
[LLVMdev] Debugging lli using bugpoint
...}
> }
>
> $ llvm-gcc -emit-llvm -o FPtrEqTest.bc -c FPtrEqTest.c
> $ llc -f FPtrEqTest.bc
> $ gcc -o FPtrEqTest FPtrEqTest.s
> $ ./FPtrEqTest
> OK!
>
> $ lli FPtrEqTest.bc
> Bad!
>
> The above test case is just a smaller version of the one in Python's
> subtype_traverse which also tests a function pointer and calls
> itself. It seems the problem arises due comparison with the stub's
> address when a comparison with the actual address of the compiled
> function is intended.
>
> thanks,
> Prakash
>
> On Mon, Nov 3, 2008 at 2:07 AM,...
2008 Oct 28
0
[LLVMdev] Debugging lli using bugpoint
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
2008 Oct 28
2
[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