similar to: [LLVMdev] Problem with running the program using LLVM

Hey All, I am running into a problem with running the program using LLVM JIT. I get the following error. lli: error loading program 'Hel.bc': Bitcode stream should be a multiple of 4 bytes in length. Hel.bc is the bytecode for my simple HelloWorld program. Please give me some insight into this. Thanks -- Abhinav Karhu MS Computer Science Georgia Institute of Technology

Hi, I am working with llvm 1.3 on a sparcv9 machine. I have successfully built llvm and llvm-gcc frontend. I can run many tools including llvmgcc, llvm-dis, and llc. After using /opt/SUNWspro/bin/cc to assemble .s file into a program binary, I can run the binary correctly as well. I am interested in the JIT compiler (lli). When I directly run the LLVM bytecode using interpretation ("lli

On Wed, 12 Apr 2006 22:48:16 -0500 Patrick Meredith <pmeredit at uiuc.edu> wrote: > > On Apr 12, 2006, at 10:23 PM, Simon Burton wrote: > > > > > Is it possible to get llvm to generate native machine code > > without using gcc and friends ? Do I use lli ? > > llc. llc --help lists all the options. it compiles llvm bytecode > files. It seems this

Hi Thanks for the info, it led to the source of the error I was having. I was using llvm-gcc binaries (built with mingw I guess) to compile a .c file that is my language runtime, llvm-link'ing that with my frontend's .ll, and using an vcpp-built lli to run the resulting bytecode. This caused the special case in X86RegisterInfo::emitPrologue for "main" to try to align the stack

Chris Lattner wrote: >> $ lli gcd_ui.bc >> ERROR: Program used external function '__gmpz_init_set_ui' which could >> not be resolved! >> >> This application has requested the Runtime to terminate it in an >> unusual way. >> Please contact the application's support team for more information. > > Try: lli -load /path/to/foo.so gcd_ui.bc

The alloca hook is in lib\System\Win32\DynamicLibrary.inc all the way at the bottom. You'll see a __MING32__ #ifdef around the definition. You just have to implement those methods and it'll work just fine. Jake On 6/24/07, Scott Graham <scott.llvm at h4ck3r.net> wrote: > > Hi > > Thanks for the info, it led to the source of the error I was having. > > I was using

On Thu, Oct 07, 2004 at 06:22:34PM -0400, Shukang Zhou wrote: > I am working with llvm 1.3 on a sparcv9 machine. I have successfully > built llvm and llvm-gcc frontend. I can run many tools including > llvmgcc, llvm-dis, and llc. After using /opt/SUNWspro/bin/cc to > assemble .s file into a program binary, I can run the binary correctly > as well. > > I am interested in the

Mike Stump wrote: >> Is it possible to use dynamic library (*.so *.dll) from bytecode? >> If "yes" - how? > > dlopen? That's be one way. Also, most systems have shared libraries > in /usr/lib and these routines are meant to be linked against and > used. For example, on darwin, there sinf is resolved from a shared > library, you declare it and call it, as

Hello. I have been trying to check, how llvm works on Solaris recently. First I have tested lli, whitch seems to execute the bytecode generated on Linux without any problems. However, llc has failed to generate valid SPARC assembler code even on the helloworld example. Here is the generated code: sakharov at trillian:~$ cat ./test.s .text .align 16 .globl main

Hey all, I compiled the code using both the -c and -S options. I can get the human readable IR but I still cannot run it using lli. The output of the IR looks like this. Can some of the information tell me about why the program is not running. ; ModuleID = 'Hel.c' target datalayout = "e-p:32:32" target endian = little target pointersize = 32 target triple =

Hi, > (2) on alpha, gcc 4.2.4. The "unknown component name: alphacodegen" > didn't use to occur. My fault, I'll fix it. The problem is that lli wants to link in JIT module, which does not exist for these targets. -- WBR, Anton Korobeynikov

I could do that, but before I venture there, if I did that, could I have llvm-gcc produce native object files (not LLVM bytecode) that way (using my pass)? thanks, -Mark On May 7, 2008, at 11:40 AM, Chris Lattner wrote: > On Wed, 7 May 2008, Mark Oskin wrote: >> Just re-sending this. Anyone have any suggestions on how to proceed >> with debugging LLVM produced executables?

Hi everyone again, I did discover the following works (see below). However, does anyone know of the "proper" way with LLVM? llvm-gcc -g -c -emit-llvm helloworld.c opt -load=mypass.dylib -mypass < helloworld.o > helloworld-mypass.o llc -fast -f -o helloworld.s helloworld-mypass.o as -o helloworld-prime.o gcc -o helloworld helloworld-prime.o gdb helloworld On May 5, 2008, at

Hello, Ralf > ERROR: Program used external function '__main' wich could not be > resolved! This was the bug fixed soon after 2.2 release. > I get the same error if I link the program with: "llvm-ld -v --stats > hello_world.bc -o hello_world.exe" > ... and execute the resulting "hello_world.exe" Right, because produced .exe just calls lli for bytecode

Hello, > If anybody has an idea of how to fix this (other than using another > version of gcc because I am sick of compiling), I would appreciate. I > can offer backtraces or shell access if anybody is interested, just > ask me what you need. This was fixed couple of months ago. Please consider using current svn top of tree, not 2.3 release. -- WBR, Anton Korobeynikov

Hi everyone, I have a question that seems simple, but has been confounding me for several hours. I'd like to debug a binary produced with LLVM. For the life of me, I can't get any symbols into gdb and llvm-db won't even start the program nor load any useful information about it. Here's my current strategy (which isn't working): llvm-gcc -g -O0 -c -emit-llvm

I think you probably need to pass -O0 to llvm-ld. The link-time optimizations are probably killing your debug info. --Owen On May 5, 2008, at 8:21 PM, Mark Oskin wrote: > Hi everyone again, > > I did discover the following works (see below). However, does anyone > know of the "proper" way with LLVM? > > llvm-gcc -g -c -emit-llvm helloworld.c > opt

> I think you probably need to pass -O0 to llvm-ld. The link-time > optimizations are probably killing your debug info. > No dice. Doing it this way makes gdb spew out this: warning: Could not find object file "/var/folders/cQ/cQ+L3+RP2RWOpE +8ZNQdPU+++TI/-Tmp-//ccVljWhn.o" - no debug information available for "defs.h" And then no debug symbols are available.

On Wed, 7 May 2008, Mark Oskin wrote: > Just re-sending this. Anyone have any suggestions on how to proceed > with debugging LLVM produced executables? The problem appears to be > register-allocated variables. Global variables and syntax lines do > get symbols using the llc / as method I described below. -Mark Have you considered adding your pass to llvm-backend.cpp in llvmgcc?

thank you! yes, i guess that is the problem. unfortunately libcmt doesn't work. could it have another name for lli? The function missing seems to be part of libcmt since i get a similar error on linking if i remove the libcmt D:\llvm\examples\helloworld>lli -load=libcmt hello.bc Error opening 'libcmt': libcmt: Can't open: The specified module could not be found. (0x7E)