similar to: [LLVMdev] Using lli

Hello, I'm trying to use DWARF informations to debug JITed code, but lli crashes when it tries to run any code coming from llvm-gcc or CLANG with the -g and -emit-llvm -c arguments. The target machine is an AMD 64 X2 processor on linux ubuntu 9.04 in x86_64 mode. Lli is generated from the current version of the svn repository. The backtrace and full bt from gdb are enclosed with this

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

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

Hi, I'm trying to follow the instructions on how to add a new bitcode instruction: http://llvm.org/docs/ExtendingLLVM.html This is my first foray into the guts of LLVM and I'm not sure I'm doing things the right way. I came up with a patch that adds a NOP (no operation) that will work with llvm-as, llvm-dis, and lli. It would be nice if one of the experts could take a look and give

I've filed PR3043 for this. Evan On Nov 3, 2008, at 4:00 PM, Prakash Prabhu wrote: > Hi Evan, > > Thanks for the pointers. We found a simple test case that causes the > problem (thanks to Tom in my group): > > #include<stdio.h> > #include<stdlib.h> > > void test(); > void (*funcPtr)(); > > int main(int argc, char **argv) { > funcPtr =

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

Hi I’ve previously used the ExecutionEngine::addGlobalMapping to make existing functions available to my JITed code. I’m currently using ORC, as MCJIT does not appear to be maintained any longer (the kaleidoscope examples have not worked for some time with MCJIT). I’m using just the basic ORC CompileLayer directly. So, I’ve essentially copied the ExecutionEngine::addGlobalMapping related

Hi Björn, I'm not sure I understand what you are actually trying to achieve. Do you want to be able to debug from your main code, and step into the JITed code? Do you want to be able to set breakpoints, list callstacks, etc in the JITed code? Do you want to, from a crash, identify where in your JITed code it went wrong? The first two are definitely one or more order(s) of magnitude harder

Thanks Evan. On 09/11/2007, at 6:50 PM, Evan Cheng wrote: >> 1. What optimization passes, if any, should I run on the module >> before I pass it to the ExecutionEngine. > > The default JIt driver, lli, runs everything. My reading of the lli source indicates that it's not explicitly doing any opt passes - is that happening implicitly in the ExecutionEngine? I can see

Hi Andy, I think that makes sense. I'm currently rewriting the core Kaleidoscope tutorials - I'll look at adding support for this. - Lang. On Fri, Aug 14, 2015 at 7:38 AM, Andy Somogyi <andy.somogyi at gmail.com> wrote: > After some fiddling with it, it does in fact look like it works as you > describe Lang. > > The trick was you had to call > >

Hi Andy, I haven't tested this on Linux, but on MacOS the RuntimeDyldMemorManager::getSymbolAddressInProcess method should find symbol addresses in the host program, including symbols from static archives linked into the program. However, one gotcha is that the symbol has to be reachable from main, otherwise the linker may strip it from the final executable. Do you have a test-case that I

Right now, GDB has no way to be told about JITed code. I'm working on adding such an interface, and the LLVM JIT would be the first client. The interface is evolving, and I'll admit that right now it's downright terrible. Here's how it works right now: - The JIT generates the machine code and DWARF call frame info (.eh_frame/.debug_frame) for a function into memory. - The JIT

Hi Gael, I tried converting to your approach but I had some issues making sure that all symbols accessed by the jit modules have entries in the dynamic symbol table. To be specific, my current approach is to use MCJIT (using an objectcache) to JIT the runtime module and then let MCJIT handle linking any references from the jit'd modules; I just experimented with what I think you're doing,

I was able to get past the error by calling InitializeNativeTargetAsmParser() in my code. Now I have a failure in resolving external libraries, so looking into that (recompiled with --enable-ffi but I now get an error LLVMgold.so not found). Then I hda to disable the following code in lib/Target/X86/X86CodeEmitter.cpp: > case TargetOpcode::INLINEASM: > // We allow inline

Lang, I added the add/get global mapping to my kaleidoscope JIT, but I think perhaps these would make more sense if they were added to the object linking layer as they would be generally usable there. On Aug 19, 2015, at 11:19 PM, Andy Somogyi wrote: > Hey Lang, > > I've added this to my Kaleidoscope JIT, and it seems to work just fine, basically I copied the global mapping

Hi Stefan, Thanks for your reply. I tried running my simple example on Linux using lli and it does work fine. So I think the best long-term solution is to migrate my code to the new lazy orc jit. Unfortunately, even the simplest example does not work on Windows: int main() { return 0; } This is the output: JITDylib "<main>" (ES: 0x000001b6e4ad3670): Search order: [

On Sep 16, 2008, at 12:17 PM, Thomas B. Jablin wrote: > > ----- "Evan Cheng" <evan.cheng at apple.com> wrote: > >> On Sep 16, 2008, at 8:44 AM, Thomas B. Jablin wrote: >> >>> Evan, >>> So, if I understand you correctly, the design you have in mind is >>> to: create a PassManager, pass it to the JIT on construction, and >>>

I am using LLVM to compile script code and then executing using the JIT compiler via the runFunction() method. The script code is contained with a C++ program compiled with G++. I am having a problem when an intrinsic function (i.e. a function implemented in C++ which is called from the LLVM compiled script) throws a C++ exception. I want the exception to be caught by the C++ code that invoked the

Thanks for the pointers. Am I correct in assuming that putting the precompiled bitcode into a second module and linking (or using the object caches) would result in ordinary function calls, but would not be able to inline the functions? -- lg On Jan 21, 2014, at 11:55 AM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > I would say that the incompatibility is by design. Not

Hi Evan, Thanks for the pointers. We found a simple test case that causes the problem (thanks to Tom in my group): #include<stdio.h> #include<stdlib.h> void test(); void (*funcPtr)(); int main(int argc, char **argv) { funcPtr = test; test(); } void test() { if(funcPtr == test) { printf("OK!\n"); } else { fprintf(stderr, "Bad!\n"); exit(1);