similar to: [LLVMdev] Basic Blocks: Bytecode -> Native Code

-----Original Message----- From: Vikram S. Adve [mailto:vadve at cs.uiuc.edu] Sent: Sunday, January 25, 2004 7:16 AM To: Joseph E. Grzywacz Subject: RE: [LLVMdev] Basic Blocks: Bytecode -> Native Code [Joseph, I'm sending this again because I didn't copy the list the first time.] Yes, this is true for the Sparc back-end. In fact, it is a fundamental assumption that is relied on by

Hi, I''ve just had my very first attempt of making a JavaScript class, "prototype" style, so please bare with me, for any disastrous errors :-) Anyway, I''ve made this class, which is called on an input field on focus: http://pastebin.com/487417 It works fine in FireFox, but causes some problems in IE. My question is regarding line 69 in the paste. What is

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 As this '-R' command initially works fine I guess it must be a bug. I have to login at a computer which is hidden behind NAT. The user (joe) at the computer then connect to my server with the command: ssh -R 1234:localhost:22 test.com Then I login to test.com and connect back to joes computer: ssh -p 1234 localhost I get successfull connection every time but after a few

On 11 Jun 2007, at 22:35, Jan Rehders wrote: > It's inside PPCJITInfo::relocate but unfortunately I could not figure > out anything from the source. It looks like it's calculating new > addresses for functions which does not make much sense for a native > function, at all On the PPC, unconditional branches are limited to 24 bit signed displacements. When you call a function

Hi Tanya and everybody, Ty for your support. I too believe it should not be complicated. But I was not being able to do it. For instance, I tried to run this code below: BB->push_back(&(BB->front())); BB->pop_front(); But it did not work (kinda obvious why). Nor this: BB->push_back(BB->begin()); BB->pop_front(); But also did not work. It seams the same

Hello, If you have one or more bytecode files with debug info, how do you generate a native executable still with debug info? I tried, for instance, this: llvm-ld -native -disable-opt -o exec file1.bc file2.bc but it doesn't seem to work. Thanks, Luís

Hi, > Jan, how are you doing this? Are you creating an external LLVM > Function > object named "get5", then using EE::addGlobalMapping? If 'get5' > exists in > the address space, why not just let the JIT resolve it (which will > then > create the stub)? Yes. I create a Function with matching signature, calling conventions and external linkage

I am trying to obtain native code from the bytecode by using commands: % llc hello.bc -o hello.s % gcc hello.s -o hello.native This is working for a simple program( a single source file) but when I try to run it on grep utility (grep.bc) , it gives me the following error: $ llc grep.bc -o grep.s $ gcc grep.s -o grep.native /tmp/ccY3oNAA.o(.text+0x2f2f): In function `main': :

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

Thanks Chris. I did inserting function into code before using the way you mentioned, such as call a external function. But coud I insert some assemble instructions into *.bc ? what I want to do is to implement polymorphic engine like ADM. It can change the binary code which looks like different but the functionality is exactly same. The simple way to do it is to add some junk code like NOP(

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

Hello, Nicolas. > This will force an indirect call, and won't use the jump-size limitation > of the bl instruction. I think we're using some logic to determine, whether call should be "direct" or "indirect" on x86. Look for GVRequiresExtraLoad() routine in the X86Subtarget.cpp -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics,

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

On Mon, 11 Jun 2007, Jonas Maebe wrote: > On 11 Jun 2007, at 22:35, Jan Rehders wrote: >> It's inside PPCJITInfo::relocate but unfortunately I could not figure >> out anything from the source. It looks like it's calculating new >> addresses for functions which does not make much sense for a native >> function, at all > > On the PPC, unconditional branches

Hi, as the current debian maintainer of the openssh package is a bit busy, I'm helping him with fixing a part of the bugs in openssh that debian users found will forward some of the reports to you. This is the first one and a fix or a comment why this should not be fixed would be appropriated. Thanks Space in filename is not correctly passed by scp to other invoked programs:

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,

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

Hi, > Okay. If the function exists in your application's address space > already, > just name the LLVM function the same name as the native function > and the > JIT should find it an do the right thing. This is how it finds > printf and > a variety of other things. You don't need to call addGlobalMapping at > all. Looking at the output of "nm