similar to: [LLVMdev] New JIT Feature

Thanks, Shu, I guess I haven't updated since my post went out. There are actually 2 problems: 1. mis-compilation: My LLVM-2.5 turned out to be mis-compiled using gcc-4.4.0 (surprise to me) on Debian4-32b. I tried a few different compilers, and gcc-4.0.4 (a relatively old one, again surprised me) seems to work out fine. Question: is there a good/quick/reliable way to figure out whether a

> Question: is there a good/quick/reliable way to figure out whether a > certain gcc compiler will mis-compile? http://llvm.org/docs/GettingStarted.html#brokengcc lists documented problems with different versions of gcc. I use gcc-4.3.2 with ubuntu 8.10 and haven't had any problems > 2. I ran into exactly the problem you pointed out. (Thank you) > The Makefile needs some update

Hey Chuck, I'm afraid I can't reproduce your error but...a problem you may run into later is that opt will complain with opt: llvm/lib/VMCore/Pass.cpp:149: void<unnamed>::PassRegistrar::RegisterPass(const llvm::PassInfo&): Assertion `Inserted && "Pass registered multiple times!"' failed. Aborted I "fixed" this by replacing the LLVMLIBS line in

Hello, I have a bytecode doing 64 bits division and on Mingw32/x86, lli complains it cannot resolve __udivdi3 when running it. Those symbols are all part of libgcc and all present in lli, but they cannot be found by SearchForAddressOfSymbol (not in any DLL). To workaround that, I explicitely define them in Win32/DynamicLibrary.inc if the current target is Mingw32 (patch attached). Anybody had

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

Hi James, 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. Best, Toan Mai On Mon, Apr 30, 2012 at 3:55 PM, James Molloy <james.molloy at arm.com> wrote: > Hi Toan, > > The JIT for ARM (non-darwin) is completely broken and you should not

The interpreter still resolves printf using a hack. It does try to use DynamicLibrary to find it, but fails. DynamicLibrary on Windows only searches the main program executable for symbols, lli.exe in this case. As the C/C++ runtime is in a DLL, it won't find printf in lli.exe. It ought to then search the runtime DLL, the name of which depends on how the binaries are built, but it

While learning to write LLVM passes and following the precise instructions under http://llvm.org/docs/WritingAnLLVMPass.html, <http://llvm.org/docs/WritingAnLLVMPass.html> I got this error when loading the hello pass to run the test program: opt -load ./Release/lib/Hello.so -hello < test/test.bc > /dev/null Error opening './Release/lib/Hello.so': ./Release/lib/Hello.so:

There's a problem with the license for ltdl.c when building with VC++. It is under the LGPL, with a special exception: As a special exception to the GNU Lesser General Public License, if you distribute this file as part of a program or library that is built using GNU libtool, you may include it under the same distribution terms that you use for the rest of that program. The problem is,

The various ExecutionEngine pieces may be the only places within LLVM that are using the DynamicLibrary stuff, but there's no telling what various LLVM consumers may be using it for. The "stat" symbols shouldn't be exposed the way they are in the old JIT memory manager location. It's not clear to me why that didn't happen inside getPointerToNamedFunction there. Is

On Sun, Oct 9, 2011 at 6:51 PM, Wei-Fan <wfchiang at cs.utah.edu> wrote: > Hello Jeff, > > Many thanks for your help!! > I successfully load a function in a dynamic library by using > sys::DynamicLibrary routines. great. > But I still have another question: > How if 'foo' is defined in a static library ?? > Is it possible not compiling the static libraries

I've got a number of problems with this patch. First, we have plans to pry apart the remaining strands connecting JIT with MCJIT, so I don't want to do anything that reconnects them. That is, I'm against moving things from RTDyldMemoryManager into ExecutionEngine. Second, unless I'm reading it wrong, this relies on static constructors. That causes headaches and is against the

Thanks for splitting up the patch. I'm not the right person to comment on the modification and access time changes (though it looks alright to me). You might want to re-submit that part on its own as it's likely to be ignored by people who aren't interested in JIT stuff otherwise. Regarding the memory manager changes, functionally this looks good. I'm not a big fan of macros,

The next problem I have is: llvm[2]: Linking Debug executable opt /home/foad/llvm/objdir-mingw/Debug/lib/libLLVMSystem.a(DynamicLibrary.o):/home/foad/svn/llvm-project/llvm/trunk/lib/System/Win32/DynamicLibrary.inc:179: undefined reference to `___eprintf' collect2: ld returned 1 exit status I can work around this by removing the two references to __eprintf from

On 11/11/13 17:42, Kaylor, Andrew wrote: > I've got a number of problems with this patch. > > First, we have plans to pry apart the remaining strands connecting JIT with MCJIT, so I don't want to do anything that reconnects them. That is, I'm against moving things from RTDyldMemoryManager into ExecutionEngine. The direction of LLVM is not something I'm in a position to

On Tue, Aug 27, 2019 at 4:56 PM Praveen Velliengiri <praveenvelliengiri at gmail.com> wrote: > > HI > Did you run the static constructor and destructor? How did you make your process symbols visible to ORC jit? Yes. It's the constructor that generates the undefined symbol error. We use DynamicLibrary::LoadLibraryPermanently(nullptr) to add process symbols. > Could you

Oh, I see now. It turns out that even knowing what the end goal was I misunderstood part of what the macros were doing. If you could add some comments explaining what the macros are doing then I guess I can live with the patch in this form. I definitely agree that it's better not to have two copies of the list. Thanks, Andy -----Original Message----- From: James Lyon [mailto:jameslyon0

On Fri, 2004-12-31 at 05:30, Francisco Puentes wrote: > Hi again, and thanks (Reid) for your fast response: Glad to help. > > Yes, it works!!! Only changing the order of libraries in the Makefile. Great! > > 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

On Sun, 28 Nov 2004, Reid Spencer wrote: > The DynamicLibrary.cpp code is written and I believe it to be complete, > but it hasn't been tested much (at all). llvm-ld uses it to load its > plug-in optimization module. The implementation will use ltdl library > if its available, otherwise it tries to use dlopen/dlsym if they are > available, otherwise you get a compile time

Committed as r194832. -----Original Message----- From: James Lyon [mailto:jameslyon0 at gmail.com] Sent: Thursday, November 14, 2013 4:58 PM To: Kaylor, Andrew; LLVM Dev Subject: Re: [LLVMdev] Android JIT patch Here's an updated version with more comments. James On 14/11/13 23:06, Kaylor, Andrew wrote: > Oh, I see now. It turns out that even knowing what the end goal was I