similar to: [LLVMdev] Why exceptions don't work in JIT?

On 06/21/2010 11:14, Reid Kleckner wrote: > Yes, I have some version of 7.1 installed on my workstation and it works for me. I repeted what you did step by step and it still doesn't work for me, see log below. Two differences: I am on FreeBSD and it's 32 bit. It's svn revision 105825. Plus I have few unrelated patched applied to it which shouldn't matter. Yuri $ lli

On Sat, Jun 19, 2010 at 8:53 PM, Yuri <yuri at rawbw.com> wrote: > I have followed http://llvm.org/docs/DebuggingJITedCode.html, used the > latest release gdb-7.1 (from March 18, 2010) and got this stack: > > (gdb) bt > #0  0x35532156 in ?? () > #1  0x355320f8 in ?? () > #2  0x35532098 in ?? () > #3  0x3553202e in ?? () > #4  0x34a5661a in ?? () > #5  0x349d9bd9

I have followed http://llvm.org/docs/DebuggingJITedCode.html, used the latest release gdb-7.1 (from March 18, 2010) and got this stack: (gdb) bt #0 0x35532156 in ?? () #1 0x355320f8 in ?? () #2 0x35532098 in ?? () #3 0x3553202e in ?? () #4 0x34a5661a in ?? () #5 0x349d9bd9 in ?? () #6 0x08052cd9 in main (argc=4, argv=0xbfbfe264, envp=0xbfbfe278) at

Since FreeBSD is an ELF target, this should work fine. I've also tested that this works in 32-bit by building gdb and llvm in 32-bit mode and testing this stuff while running on a 64-bit OS. I would try setting a breakpoint in gdb on 'llvm::JITDebugRegisterer::RegisterFunction' to see that it is being called, and that getELFWriterInfo returns something. If that function actually

Here is what I did: I took c.C (attached), compiled it into my.ll code with command 'clang++ -O3 -fexceptions -emit-llvm -S -o my.ll c.C' and added tracing command on every line, see attached my.ll Running my.ll in interpreter with this command 'llvm-as my.ll && lli -jit-enable-eh my.bc', I get this log: TRACE num=20 TRACE num=22 TRACE num=27 TRACE num=29 TRACE num=31

Have you found http://llvm.org/docs/DebuggingJITedCode.html? The JIT already has support for something like this for gdb's benefit. Perftools and valgrind just don't know how to find it yet. On Sat, Jun 19, 2010 at 2:03 PM, Yuri <yuri at rawbw.com> wrote: > This new option (--jit-emit-debug-function-range) will allow to output > function information for memory ranges that

In r134967 it still worked, and in r137742 it now doesn't. I used such flags: --enable-assertions --enable-shared --enable-libffi --enable-debug-runtime --enable-debug-symbols --disable-optimized Before build would create directory tools/llvm-shlib under the build tree. Now it is missing. Yuri

On 06/21/2010 14:14, Reid Kleckner wrote: > Since FreeBSD is an ELF target, this should work fine. I've also > tested that this works in 32-bit by building gdb and llvm in 32-bit > mode and testing this stuff while running on a 64-bit OS. > > I would try setting a breakpoint in gdb on > 'llvm::JITDebugRegisterer::RegisterFunction' to see that it is being > called,

Yuri, on which host? 2011/8/17 Yuri <yuri at rawbw.com>: > In r134967 it still worked, and in r137742 it now doesn't. > I used such flags: --enable-assertions --enable-shared --enable-libffi > --enable-debug-runtime --enable-debug-symbols --disable-optimized > > Before build would create directory tools/llvm-shlib under the build > tree. Now it is missing. In my

On 06/21/2010 18:01, Reid Kleckner wrote: > One thing you could do as a temporary work around is to link with LLVM > statically. There's already an open bug where if the JIT is in a > shared library, then you cannot run the program twice under gdb > without restarting gdb, which is really annoying. > > This affects me, and I do intend to fix it eventually. I'm not sure

This new option (--jit-emit-debug-function-range) will allow to output function information for memory ranges that functions occupy in memory while they run in JIT. File format generated is like this: ... 0x5000000 0x5001000 function_name_is_here ... This feature is useful for external tools like valgrind and google-perftools to profile the code when it is run in JIT. Particularly

I run some code in JIT on x86-64 architecture. Even though llvm::NoFramePointerElim is set to true, I still see weird stack in gdb, see below. 800b485a4 is the current rip register where gdb stopped. Then many others values aren't valid. Then there is value that looks ok again. Why gdb can't determine stack? Yuri -- stack -- #0 0x0000000800b485a4 in ?? () #1 0x000000000000005f in

This new option will allow to output function information in the same format as addr2line from binutils emits: ... 0xABCDEF01 T function_name_is_here ... This feature is useful to profile the code when it is run in JIT by external tools like valgrind and google-perftools. For example, google-perftools runs addr2line on executable and uses the resulting file to resolve memory addresses to

On 02/02/2014 01:48, David Chisnall wrote: > In most calling conventions, this is a callee-save register. After its last use, the register allocator may reuse that register. On x86 and ARM, the register that contains this is also (usually) the register used for But the rule "after the last use, the register allocator may reuse it" is also introduced by llvm, since register

I have this situation when the same code SEGVs in JIT with option -disable-fp-elim and works fine without it. How can this possibly happen? Is it possible that there is a bug in JIT that stack isn't properly lowered for local variables when prologs are present? Or maybe JIT can accidentally use ebp for some values when it's supposed to be only used by frame pointer value. Stack (see

I need to know how deep is the stack allocated for the process (total for all functions)? How to set this size? Yuri

Török Edwin wrote: > Are you using 2.6 or 2.7, 32-bit or 64-bit? > I use 2.7 on i386. lli has debug asserts enabled, but I guess this shouldn't matter for JIT code speed. jit: 11.32 real exe: 7.64 user Both have -O3 option. Speed should be the same. Yuri

On 06/19/2010 14:14, Jeffrey Yasskin wrote: > Have you found http://llvm.org/docs/DebuggingJITedCode.html? The JIT > already has support for something like this for gdb's benefit Yes, I saw it and tried it. -jit-emit-debug generates ELF image in memory with debug info. Another option -jit-emit-debug-to-disk creates .o ELF files with debug info, one per function. If there are thousands

When for example some call is wrong error message always looks like this: Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i) == Params[i]->getType()) && "Calling a function with a bad signature!"), function init, file /tmp/llvm-svn/llvm/lib/VMCore/Instructions.cpp, line 247. I believe assert() statements should better be replaced with more

On 10/02/2012 13:01, Duncan Sands wrote: > > I think Chris is the right person to look at this, hopefully he will. Now 5 months passed. I updated the patch for this current revision. Can anybody review this and check in please? http://llvm.org/bugs/show_bug.cgi?id=13163 Yuri