similar to: [LLVMdev] how to debug with interpreter

x/20i $pc - 20 or so is your friend. In general, you can't disassemble x86 backwards, but gdb does a reasonably good job if you just guess. Alternatively, if you're on Linux, there's the gdb-jit interface, which should give you symbols and unwind tables without any extra effort on your part: http://llvm.org/docs/DebuggingJITedCode.html To answer your original question about the

On Sun, Mar 20, 2011 at 11:56 AM, Reid Kleckner <reid.kleckner at gmail.com> wrote: > Alternatively, if you're on Linux, there's the gdb-jit interface, > which should give you symbols and unwind tables without any extra > effort on your part: > http://llvm.org/docs/DebuggingJITedCode.html This page says to run `lli -jit-emit-debug myfile.bc' under gdb. Does the

On Tue, Aug 10, 2010 at 1:35 PM, Eric Christopher <echristo at apple.com> wrote: > > On Aug 10, 2010, at 1:30 PM, Bueno, Denis wrote: > >> Running lli under gdb gives >> >> Program received signal SIGSEGV, Segmentation fault. >> [address] in ?? () >> (gdb) bt >> #0 [address] in ?? () >> Cannot access memory at address [address2] >>

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 Aug 10, 2010, at 4:09 PM, Reid Kleckner wrote: > On Tue, Aug 10, 2010 at 1:35 PM, Eric Christopher <echristo at apple.com> wrote: >> >> On Aug 10, 2010, at 1:30 PM, Bueno, Denis wrote: >> >>> Running lli under gdb gives >>> >>> Program received signal SIGSEGV, Segmentation fault. >>> [address] in ?? () >>> (gdb) bt

On Aug 10, 2010, at 5:09 PM, Reid Kleckner wrote: No, he's just on linux x86_64 using JITed frames with no unwind information. That was the whole point of adding the support here: http://llvm.org/docs/DebuggingJITedCode.html See if you can get a stack trace using the directions there. I had followed the directions on that page with llvm 2.6 to no avail. The Makefile I posted does use

Thanks Reid - I'm on Windows. I guess I just assumed I was missing something obvious in how to hook up the JIT and disassembler! Given the nice looking disassembly code I found, I thought people would be doing it all the time :-) b. On Tue, Jul 6, 2010 at 8:41 PM, Reid Kleckner <reid.kleckner at gmail.com> wrote: > If you're on a recent flavor of Linux, you may be able to just

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

Hi, With the new llvm-mc code for disassembling, what is the recommended way to disassemble the final code produced by a JIT compiler backend? (Eg. in the toy.cpp example from the tutorial). I can get the void* for the final code, but I don't know its length - superficially at least it appears I need to know the length to disassemble it as a buffer? Thanks b.

Unfortunately, the current gdb support doesn't include line numbers. It'll tell you what function it crashed in and the stack trace though. Line numbers will probably come when the llvm-mc project is merged into the JIT. On Tue, Feb 9, 2010 at 9:37 AM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > Are you running this in a JIT? If so this will help:

I would like to use bugpoint to debug some of my passes. I have read the documentation, but I don't completely understand it. I have a bitcode file X.bc that I transform using the following commands: opt -mypass1 -f -o X.1.bc X.bc // transform with mypass1 llvm-link -f -o X.2.bc X.1.bc support.bc // link with support.bc opt -mypass2 -f -o X.3.bc X.2.bc // transform with mypass2 After

On Dec 6, 2010, at 2:18 AM, Ryan M. Lefever wrote: > > llc X.3.bc arg1 arg2 > > That llc command is currently seg faulting because of a bug in one of my > passes or in support.bc. Can I use bugpoint to find a smaller version of > X.bc that produces the same problem? Specifically how would I call > bugpoint to do that? bugpoint X.3.bc -run-llc -tool-args arg1 arg2 /jakob

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

Hey guys, I'd need to debug just-in-time compiled code under Mac OS. As predicted, GDB doesn't cope really well with it. The LLVM manual seems to say it's possible to patch GDB under Linux, but there seems to be no option for Mac OS. What can I do? I'd prefer a solution that integrates with Xcode, but I'll manage if it doesn't and I have to run the debugger externally.

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

I'm trying to run the example described at: http://llvm.org/docs/DebuggingJITedCode.html I followed the sample command line session (below, with versions numbers for everything), but gdb doesn't stop at the breakpoints as described. Any idea what is wrong? Thanks, Zach zdevito at derp:~/terra/tests$ > ~/clang+llvm-3.4-x86_64-unknown-ubuntu12.04/bin/clang -cc1 -O0 -g >

If you're on a recent flavor of Linux, you may be able to just go into gdb and type "disas <pointer-to-JITed-code>". More detail here: http://llvm.org/docs/DebuggingJITedCode.html If you still want to do it programmatically, I think you might be stuck. IIRC the length known by the JIT memory allocator is an overestimate (it's rounded up for alignment), so the

I suspected something like that. :( I was hoping i could run the program and step throught IR-Code line by line, maybe even have a look at the variables. Well, what about compiling it into assembler-code. Is there any way to know which IR-line generated which assembler line(s)? (I do not need any optimizations or whatever, if that helps...) Sebastian On Tuesday 09 February 2010 18:45:56 you

Just a quick question on LLVM, signals, and the lli interpreter. A sample program is included at the end. Platform is x86, Linux, 32-bit, GCC 4.2.4. Does lli -force-interpreter support signals, or is it only the JIT that does? The following sample program crashes with lli 2.5 and lli top-of-tree. Thanks and regards, Matt ============================= #include <stdio.h> #include

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