similar to: [LLVMdev] How to set JIT stack depth allocated for the process?

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

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

When I try running simple example with exceptions through JIT I get this output: terminate called after throwing an instance of 'E*' Why exceptions don't work in JIT and what it takes to make them work? Yuri --- e.C --- #include <stdio.h> #include <stdlib.h> class E { }; void xmain() { try { throw new E; } catch (E *e) { printf("caught!\n");

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

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

I know you haven't been able to get the JIT gdb support to work on FreeBSD (right?), but this is exactly the problem that we ran into that it solves. http://llvm.org/docs/DebuggingJITedCode.html I don't know what heuristic gdb is trying to use to unwind the stack, but it doesn't work. I asked a gdb developer about it two summers ago when I was working on this, but he seemed

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,

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

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

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 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

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 Apr 17, 2013, at 7:26 PM, Yuri <yuri at rawbw.com> wrote: > 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 >

This function (understandably) takes quite a long time, because it has to go through each function in module and write its binary. But it probably can be parallelized if different threads would write binaries separately, and then merge them together. Is this implemented or planned? Yuri

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

How can I copy the value from another BB? PHI instruction with one argument would fit, but it requires that all arguments are in immediately preceding BBs. Yuri

I've built clang+llvm in an object directory successfully, and I'm sure others have. I'd guess the problem is the symlink, so I'd give it a shot without it. Reid On Thu, Jun 10, 2010 at 7:43 AM, Diego Iastrubni <diegoiast at gmail.com> wrote: > can you tell what commands exactly did you use? > > What I usually do is: > > svn co llvm... > mkdir

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

This is maybe a minor issue, but it is obvious when one looks at debug info produced by clang. Such records are normally created by the code like this: Instruction->setDebugLoc(llvm::DebugLoc::get(Line, Column, Scope)); and it appears that Column is always zero. Yuri

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