similar to: [LLVMdev] Running LLVM JIT on qemu-system-arm

Hi all, I'm struggling to get lli work on qemu-system-arm. I already boot the system with a debian squeeze rootfs which contains a statically cross-compiled lli for armel. When I run ./lli hello.bc, I got the following error msg: ./lli: error creating EE: /lib/: cannot read file data: Is a directory afaik, this error is related to lli using dlopen() with a NULL path to resolve symbols for

> Thanks for your information.  > Could you suggest any other framework that I could use for making a custom JIT > for ARM? > I am doing research on JIT compilation for a heterogeneous processor system. If not for heterogeneous system, I would suggest QEMU. :) Why not try to fix it? Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science,

Could you tell me the current status of MIPS JIT? On Mon, Apr 30, 2012 at 11:38 PM, 陳韋任 <chenwj at iis.sinica.edu.tw> wrote: > > Thanks for your information. > > Could you suggest any other framework that I could use for making a > custom JIT > > for ARM? > > I am doing research on JIT compilation for a heterogeneous processor > system. > > If not for

On Tue, May 01, 2012 at 11:11:44AM +0900, Toan Mai wrote: > Could you tell me the current status of MIPS JIT? According to [1], the support for "old-style" JIT is complete. You can give it a shot. > I'm afraid it's not straightforward to fix it, Chen. Well, no pain no gain. ;) Regards, chenwj [1] http://llvm.org/releases/3.0/docs/ReleaseNotes.html#whatsnew --

Winbind appears to lose connections every once in a while. Is there a way to tell which Domain Controller winbind is making connections to? I have 3 DCs currently and trying to track down the problem. Thanks, Toan

On Fri, Jul 8, 2011 at 9:30 AM, Karel Gardas <karel.gardas at centrum.cz> wrote: > On 07/ 8/11 05:26 PM, Eli Friedman wrote: >> >> Given that revision range, the only remotely likely culprit is 131463. >>  Which basically means that it "broke" because the default target >> features changed. > > And you are right here. 131463 == 131464 which is

Resending, any pointers are much appreciated. On 5/7/2012 11:16 PM, Ashok Nalkund wrote: > > > On 5/7/2012 10:17 PM, Bendersky, Eli wrote: > <snip> >>>> $lli -entry-function="ISimEngine_GetVersion" -use-mcjit libengine.bc >>>> LLVM ERROR: Inline asm not supported by this streamer because we don't >>>> have an asm parser for this

Hello all, I'm brand new to using LLVM and am having trouble using lli with a C++ program. I tried to compile the following: #include<iostream> using namespace std; int main() { cout << "Hello, world!" << endl; return 0; } When I compile directly to an executable with the following command, all is well: $ clang++ -O3 hello.cpp -o hello But when I try to produce

On 04/03/2012 03:13 PM, Hongbin Zheng wrote: > Hi Yabin, > > Instead of compile the LLVM IR to PTX asm string in a ScopPass, you > can also the improve llc/lli or create new tools to support the code > generation for Heterogeneous platforms[1], i.e. generate code for more > than one target architecture at the same time. Something like this is > not very complicated and had

> $ clang++ -O3 -emit-llvm hello.cpp -c -o hello.bc > $ lli hello.bc > LLVM ERROR: Program used external function > '_ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l' > which could not be resolved! What version of LLVM and Clang you are using? I have no such problem on my machine. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab,

Every day, I get this error message. It's always around 4:02AM. Jul 6 04:02:10 print-server nmbd[3069]: [2006/07/06 04:02:10, 0] nmbd/nmbd.c:process(596) Jul 6 04:02:10 print-server nmbd[3069]: Got SIGHUP dumping debug info. Jul 6 04:02:10 print-server nmbd[3069]: [2006/07/06 04:02:10, 0] nmbd/nmbd_workgroupdb.c:dump_workgroups(284) Jul 6 04:02:10 print-server nmbd[3069]:

On 5/7/2012 10:17 PM, Bendersky, Eli wrote: <snip> >>> $lli -entry-function="ISimEngine_GetVersion" -use-mcjit libengine.bc >>> LLVM ERROR: Inline asm not supported by this streamer because we don't >>> have an asm parser for this target >> >> I also tried other variations of the call with the same result: >>> $lli

On Wed, Apr 4, 2012 at 4:49 AM, Tobias Grosser <tobias at grosser.es> wrote: > On 04/03/2012 03:13 PM, Hongbin Zheng wrote: > > Hi Yabin, > > > > Instead of compile the LLVM IR to PTX asm string in a ScopPass, you > > can also the improve llc/lli or create new tools to support the code > > generation for Heterogeneous platforms[1], i.e. generate code for

Dear Ciao, Duncan, I am using linux--Intel X86-64. Do I need to implement an asm parser for LLVM JIT myself or there exists some tools for it? Thank you. BestAndy Hi Andy, On 25/09/12 14:19, Zhoujinguo wrote: > Sorry that I have implemented nothing for it. inline asm won't work without an asm parser, which is something that knows how to turn assembler strings like "mov %eax,

Hi Yabin, Instead of compile the LLVM IR to PTX asm string in a ScopPass, you can also the improve llc/lli or create new tools to support the code generation for Heterogeneous platforms[1], i.e. generate code for more than one target architecture at the same time. Something like this is not very complicated and had been implemented[2,3] by some people, but not available in LLVM mainstream.

Hi Andy, On 25/09/12 14:19, Zhoujinguo wrote: > Sorry that I have implemented nothing for it. inline asm won't work without an asm parser, which is something that knows how to turn assembler strings like "mov %eax, %ebx" into opcodes, i.e. the numbers which, when placed into memory, cause the processor to execute the "mov %eax, %ebx" operation. After all, an

It seems to me that MCJIT would be a nice default on the platforms that support it. On the other hand, I don't like the idea of the default behavior being platform dependent. Perhaps the biggest obstacle to changing the default is that it would have complicated implications for the automated tests. The testing of JIT and MCJIT is already a bit of a mess, and changing the default to MCJIT

Hi LLVMers, The attached patch adds a new Intrinsic named "llvm.codegen" to support embedded LLVM IR code generation. **The 'llvm.codegen' intrinsic uses the LLVM back ends to generate code for embedded LLVM IR strings. The code generation target can be same or different to the one of the parent module. The original motivation inspiring us to add this intrinsic, is to

Hi, all It seems that rev. 131463 [1] makes LLVM failed to recognize ARM correctly. My best guess is the variable LLVM_HOSTTRIPLE got something like "armv7l-unknown-linux-gnueabi" when LLVM compiled natively on ARM. Then the Arch (armv7l) is not recognized by LLVM. As you can see from attach (llvm-131463-gcc-4.4.1-native-arm2.log), there are a lot failure while running test cases

Hi Justin, Thanks very much for your comments. 2012/4/28 Justin Holewinski <justin.holewinski at gmail.com> > On Fri, Apr 27, 2012 at 7:40 PM, Yabin Hu <yabin.hwu at gmail.com> wrote: > >> The attached patch adds a new Intrinsic named "llvm.codegen" to support >> embedded LLVM IR code generation. **The 'llvm.codegen' intrinsic uses >> the