similar to: [LLVMdev] How difficult is to fix this error: JIT does not support address-of-label yet!

I just implemented this feature and here is the patch: http://llvm.org/bugs/show_bug.cgi?id=7264 Yuri

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

On Mon, Jun 21, 2010 at 5:14 PM, Yuri <yuri at rawbw.com> wrote: > I am on FreeBSD and gdb-7.1 seems to be broken. It fails to set breakpoints > in shared libs. using symbol-file causes this message: > > (gdb) symbol-file /usr/local/llvm/svn-r105825.dbg/lib/libLLVM-2.8svn.so > Load new symbol table from > "/usr/local/llvm/svn-r105825.dbg/lib/libLLVM-2.8svn.so"? (y

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,

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

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

You said this is on 32-bit x86? My understanding is that in that case, gdb will use ebp/esp to unwind the stack and doesn't need dwarf. It may have different behavior on FreeBSD if frame pointers are normally omitted on that platform. gdb ignores them on Linux x86_64 because they are generally omitted. This might actually be the best explanation for your symptoms, since this is what a gdb

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

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

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

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

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

On 06/19/2010 14:03, Yuri wrote: > 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 >

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

----- Original Message ---- > From: Chris Lattner <clattner at apple.com> > To: Yuri <yuri at rawbw.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Sun, February 20, 2011 3:26:35 AM > Subject: Re: [LLVMdev] Announcing: LLVM 2.9 Tentative Release Schedule > > > On Feb 19, 2011, at 8:05 PM, Yuri wrote: > > > On 02/19/2011 14:52, Yuri wrote: > >>