similar to: [LLVMdev] A first!

On Wed, Dec 22, 2004 at 08:48:19PM -0800, Jeff Cohen wrote: > I compiled a simple "hello world!" C program on FreeBSD, transfered > the a.out.bc file to Windows, and executed it with an lli.exe that I > built with Visual Studio. It worked! Great news, but note that not all bytecode files are so portable. :) -- Misha Brukman :: http://misha.brukman.net ::

Turns out it wasn't using the JIT. It was running the interpreter. The X86 stuff wasn't being linked in. Alas, once I "fixed" that, it stopped working. The JIT couldn't resolve the symbol "printf" and failed. But the interpreter could resolve it. Misha Brukman wrote: >On Wed, Dec 22, 2004 at 08:48:19PM -0800, Jeff Cohen wrote: > > >>I

Misha, The "equivalent of dlsym" should be working just fine. Its called ltdl (libtool dynamic library) and is part of lib/System. Its interface is the DynamicLibrary class. The interpreter has already been modified to use this facility. So, if this is broken on windows, I'd like to know how, or why. Jeff, can you provide a test case that we can use to reproduce this problem?

Here's the patch to Signals.cpp. assuming that stdio.h is acceptable (can't imagine it won't work). On Fri, 24 Sep 2004 09:29:05 -0700 Jeff Cohen <jeffc at jolt-lang.org> wrote: > Uh... this may be a silly question, but why can't you include <stdio.h>? > It'd be much better than <iostream>. > > Anyway, I think I'll try this weekend to come

Sigh... take it up with Microsoft. On Fri, 24 Sep 2004 12:06:36 -0500 Misha Brukman <brukman at uiuc.edu> wrote: > On Fri, Sep 24, 2004 at 09:38:44AM -0700, Jeff Cohen wrote: > > Here's the patch to Signals.cpp. assuming that stdio.h is acceptable > > (can't imagine it won't work). > > We prefer #include <cstdio>, since this is C++ after all. :) >

LLVM, When we recompile, is it possible to "make" only one of the tools, or at least relink only the tools whose object files have changed? Thanks Dave

On Fri, Dec 31, 2004 at 02:30:00PM +0100, Francisco Puentes wrote: > Now I have other problem: I have a Module and I need generate a > iostream (memory) with native x86 code (maybe elf/coff) to be executed > later (into the guest process space, without fork!!). I studied llc > and lli, but they don't help me much. Any idea? Are there any guy > working in some like that? In

Actually, <algorithm> is not correct. This remove is in stdio.h and io.h in VC7.1. It removes a file, not elements from a collection. The proper solution is to not use remove at all and use Path::destroy_file(). On Fri, 24 Sep 2004 08:09:37 -0700 Jeff Cohen <jeffc at jolt-lang.org> wrote: > <algorithm> works too. > > On Fri, 24 Sep 2004 10:09:21 -0500 > Alkis

<algorithm> works too. On Fri, 24 Sep 2004 10:09:21 -0500 Alkis Evlogimenos <alkis at cs.uiuc.edu> wrote: > On Fri, 2004-09-24 at 09:43, Paolo Invernizzi wrote: > > Jeff Cohen wrote: > > > > >But I compiled that under vc7.1 as it was! > > > > > > > > ;-(( > > > > Probably is an implicid includes, but I'm using the

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

> >>> Would be great if we append into the documentation several "patters" > >>> to show how perform with LLVM. It would accelerate the learn curve for > >>> beginners like me, avoiding basic errors and mistakes. If I reach a > >>> good level with LLVM I can make these. > >> > >> I'm not sure if I understand what you

hi, I'm really new to llvm. I've successfully bootstrapped llvm-14 on my system and am able to successfully compile c code to llvm. the problem is now that gccld is complaining that it can't find the libraries, like "c" or "crtend". [1] all is fine, if I just use intrinsified functions like printf and friends, but I want to use the clock_gettime function and

On Wed, 2004-08-04 at 07:38, Misha Brukman wrote: > On Wed, Aug 04, 2004 at 01:17:24AM -0500, Chris Lattner wrote: > > On Tue, 3 Aug 2004, Reid Spencer wrote: > > > I'm not thrilled with llvm-gen because it has overtones of "code > > > generation" (which actually isn't far from the truth). But, it > > > conjures up the wrong kind of tool ..

On Sat, Jan 08, 2005 at 06:16:47PM +0100, Francisco Puentes wrote: > I have points 0-4 working, but I am confused about point 5 and maybe 6. [snip and reorder] > (5) Generate native (x86) code from generated module The JIT currently is built to generate native code for a given module, a function-at-a-time. That means that first, main() is generated, and anything main() calls is not. As

Hi Chris, It did compile when I gave that option. But it gives me an error when I try to run the executable on an Intel machine. ----- 1513158 is not prime. Exception handler needed, but not enabled. Recompile program with -enable-correct-eh-support. lli[0x8429bb4] lli[0x8429dc0] /lib/libc.so.6[0x40128c18] /lib/libc.so.6(abort+0x161)[0x40129cb5] [0x403da922] ../../../i386: line 4: 27606

Hi again, and thanks (Reid) for your fast response: Yes, it works!!! Only changing the order of libraries in the Makefile. Nowaday I have my software with the capability of compile assembly, bytecode (from buffer and file) and link them with a set of libraries. It seems to work perfectly (I don't generate code yet). My real aim is to have a process (host) with execute several no-jit

Karl, I think you meant to cc the llvmdev list on this. Thank you for a more detailed explanation, it's much clearer to me now. I agree that making the execution of .bc files more transparent would make it more useable as a stand-alone binary format on Unix-like systems and adding programmable support to changing the #! line would prevent much of user error involved in modifying the run

> Yes, this is no problem. You can do something like > this: > > $ llvmgcc X.c -c -o X.bc > $ llc X.bc -o X.s > $ gcc Y.c -o Y.o -c > $ gcc X.s Y.o -o program > $ ./program Ok, fine, and what about the interpreter? It takes 100% llvm, doesn't it? Or is there some kind of import facility (perhaps as an specially interpreted call or as an extension to llvm which makes

Thanks Misha. I tried the "gcc -dM -E /tmp/file.c | grep __sparcv9" but there was no output. Maybe this is the probelm, I do have CXX = g++ -mcpu=v9 CC := gcc -mcpu=v9 in the Makefile.config. Do I need to add -m64 as well? Thanks. Shukang On Thu, 7 Oct 2004, Misha Brukman wrote: > Is your compiler configured to define __sparcv9 when it compiles? > The following should tell

Hi, Sorry for the newbie question. I downloaded llvm and tried out the simple "Hello, World" program but got the following error. What am I missing? I am running RHAS 3 Update 4 with GCC 3.2.3. Thanks, Bharadwaj $ ./hello lli: /home/proj/skokomish/syadaval/ia32/Sandbox/llvm/lib/Target/X86/X86CodeEmitter.cpp:208: unsigned char ModRMByte(unsigned int, unsigned int, unsigned int):