similar to: [LLVMdev] failed assertion in PPCJITInfo.cpp when calling native function

Hi, I am trying to generate LLVM code that calls a "native" function in the parent program (the program hosting the JIT). I think that I have figured out how to do this, but I get the following assertion failure when the LLVM code is executed: ../llvm/lib/Target/PowerPC/PPCJITInfo.cpp:206: failed assertion `ResultPtr >= -(1 << 23) && ResultPtr < (1 << 23)

Hi Andreas, > /llvm/lib/Target/PowerPC/PPCJITInfo.cpp:206: failed assertion > `ResultPtr >= -(1 << 23) && ResultPtr < (1 << 23) && "Relocation out > of range!"' > ... > So how is this supposed to work? Is it wrong that the memory block for > the JIT code is allocated too far off or should a non PC relative jump > be generated

> Are you able make calls to well known external functions such as > printf? As far as I known, this capability is well tested on x86 / > Linux. Calling printf works at least on OS X (I'm waiting for a reply whether this works on linux). If I call my native function it fails with PPCJITInfo.cpp:382: failed assertion `ResultPtr >= -(1 << 23) && ResultPtr < (1

Hi Jan, If I recall correctly, in Linux you get the message: PPCJITInfo.cpp:382: failed assertion `ResultPtr >= -(1 << 23) && ResultPtr < (1 << 23) && "Relocation out of range!"' Right? But on OS X you don't have this messsage? Here's a temporary fix until I find time to investigate on this: In function PPCISelLowering::LowerCALL,

Hi Jan, > Calling printf works at least on OS X (I'm waiting for a reply > whether this works on linux). If I call my native function it fails > with PPCJITInfo.cpp:382: failed assertion `ResultPtr >= -(1 << 23) && > ResultPtr < (1 << 23) && "Relocation out of range!"' I know nothing about this, but the failed assertion suggests the

Hi all. I'm working on the recently-announced unladen-swallow project, and I'm having a bit of trouble getting gdb to step into functions I've compiled with LLVM's JIT compiler. The attached a_module.ll is the module I produce from compiling def foo(r): for i in r: pass I'm JIT-compiling and running foo() with: typedef PyObject *(*NativeFunction)(PyFrameObject *);

Run with -debug-only=jit. Break on line 1148 of JITEmitter.cpp. The debugging message will tell you the address and size of the function that was jitted. You can then tell gdb to disassemble the code. On Mar 26, 2009, at 11:35 PM, Jeffrey Yasskin wrote: > Hi all. I'm working on the recently-announced unladen-swallow project, > and I'm having a bit of trouble getting gdb to

Hi, > If I recall correctly, in Linux you get the message: > > PPCJITInfo.cpp:382: failed assertion `ResultPtr >= -(1 << 23) && > ResultPtr < (1 << 23) && "Relocation out of range!"' > > > Right? But on OS X you don't have this messsage? Not exactly. There seem to be two problems. Your patch fixes one of them: in OS X I

Hi, attached is a small testcase I did. It builds two LLVM functions which both call two native functions get5 and get6. The native functions are in the exe and in the dll. On OS X it works like a charm. On Linux none of the two functions can be called. Maybe someone can try them or have a look at it to see if there is something obviously wrong greetings, Jan -------------- next part

Ok, thanks for the reply. > In other words, the code generator needs improving to cope with a jump > to an address that is too far away for a PC-relative jump. Should I file this as a bug? If no one better suited is willing to look at this soon, I am willing to give it a try. Any suggestions? Look at the x86 llvm backend and how gcc does it? Regards, Andreas

Are you able make calls to well known external functions such as printf? As far as I known, this capability is well tested on x86 / Linux. I am wondering if there is some name mangling issue? Evan On Jun 7, 2007, at 8:38 AM, Jan Rehders wrote: > Hello, > > can anyone help me calling native functions from LLVM-Bytecode > functions run in the JIT? > > I have a program

Hello, can anyone help me calling native functions from LLVM-Bytecode functions run in the JIT? I have a program which creates an LLVM execution engine and adds modules and functions to it on the fly. I need to call some native functions of my program from bytecode functions which causes some troubles as it appears not to be documented. My test scenario works like the following: I have

On Fri, Mar 27, 2009 at 3:48 PM, Evan Cheng <evan.cheng at apple.com> wrote: > Run with -debug-only=jit. OT: I take it the recommended model for tools that embed LLVM is for them to accept all of LLVM's command line arguments on their own command lines? For Python, it'd be much nicer to make this stuff tweakable through a module at runtime, or even, for thread-safety reasons, as

Chris Lattner wrote: > On Mon, 16 Jun 2008, Gary Benson wrote: > > When you genetate code on PowerPC you need to explicitly > > invalidate the instruction cache to force the processor to reread > > it. In LLVM there is code to do this for function stubs on > > Macintosh, but not for other platforms and not for JITted code > > generally. > > Applied, thanks!

+llvmdev 2009/7/3 Merkulov Aleksey <steel1.0 at mail.ru>: >> > Hello!  Working with LLVM JIT-compiler I found a small bug and I'd like to correct it.  Namely, on some tests LLVM fails with message "JIT: Ran out of space for generated machine code!" >> >> I'm working on a patch to fix this, although I've heard DOE may change >> the

All, The following patch fixes the build breakage on FreeBSD/powerpc: Index: lib/Target/PowerPC/PPCJITInfo.cpp =================================================================== --- lib/Target/PowerPC/PPCJITInfo.cpp (revision 51432) +++ lib/Target/PowerPC/PPCJITInfo.cpp (working copy) @@ -72,7 +72,7 @@ extern "C" void PPC64CompilationCallback(); #if (defined(__POWERPC__) ||

Hello! Working with LLVM JIT-compiler I found a small bug and I'd like to correct it. Namely, on some tests LLVM fails with message "JIT: Ran out of space for generated machine code!" This error emerges because the test creates big static array. Global variables are placed into memory block for function, that is first seen using given variable. Besides, during memory allocation

AIX 7.1 & Power5 I have downloaded the llvm source and ran the following steps: 1. ./configure --enable-targets=powerpc 2. gmake Apart from it, i had to make a few changes. i. dladdr code has been commented for the time being and using the default constructor code for that method ii. In Makefile.config, 2 changes were done. +153 # Linker flags. +154 LDFLAGS+=-Wl,-G,-bexpfull +211

Hi, > I know nothing about this, but the failed assertion suggests the PPC > code generator can't cope with a constant that's bigger than > expected at > that point. Have you taken a look at PPCJITInfo.cpp:382? It may shed > some light. It's inside PPCJITInfo::relocate but unfortunately I could not figure out anything from the source. It looks like it's

Hi Andrew, Andrew Haley wrote: > Here's my problem, which I raised on IRC: > > JIT::getPointerToFunction gets the address of the start of a function. > But how do I find out where the end of the function is? I need this > to register the function for profiling. > > varth said: aph, you need to intercept the "endFunctionBody" call on > the memory manager, it