similar to: [LLVMdev] Interactions with threads and native code

On Tue, 8 Feb 2005, Evan Jones wrote: > I have just begun investigating LLVM because it seems like it might be an > ideal tool for building tools for playing with software. However, my current > project is related to parallel programming on shared memory multiprocessor > systems, so I need thread support. As far as I can tell, LLVM currently has > no intrinsic support for

On Feb 8, 2005, at 21:36, Chris Lattner wrote: > That is correct. If you try to run threaded programs in the JIT, it > might run into problems if multiple functions need to JIT functions at > the same time. This should be very simple to deal with, we just > haven't had anyone take up the task yet. Only the JIT is affected > here, not the static code generator or C

On Tue, 8 Feb 2005, Evan Jones wrote: > On Feb 8, 2005, at 21:36, Chris Lattner wrote: >> That is correct. If you try to run threaded programs in the JIT, it might >> run into problems if multiple functions need to JIT functions at the same >> time. This should be very simple to deal with, we just haven't had anyone >> take up the task yet. Only the JIT is

On Feb 8, 2005, at 23:52, Chris Lattner wrote: > That would be great. As a first implementation, I would suggest > adding a lock to the ExecutionEngine class in > include/llvm/ExecutionEngine/ExecutionEngine.h, locking it when > particular state is accessed. Note that the JIT subclasses this in > lib/ExecutionEngine/JIT/JIT.h, so its accesses should be synchronized > as

> 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

I use LLVM 2.9. By the way, I have another question. Is landingpad instruction is already implemented in JIT or I should use the old approach with llvm.eh instrinsics? Thanks. 2011/11/9 Eric Christopher <echristo at apple.com> > Which version of LLVM? At any rate I don't recall TLS working for the JIT. > It may take some work. > > -eric > > > On Nov 9, 2011, at

Hi, I was able to try this on linux again. Unfortunately it doesn't work at all (neither using runFunction nor a CallInst). It simply says function called get5 not known. Calling printf the same way works, though. On linux the function is exported as "get5" from the executable while it is called "_get5" on OS X. I could not spot any other differences.. any

Which version of LLVM? At any rate I don't recall TLS working for the JIT. It may take some work. -eric On Nov 9, 2011, at 4:46 AM, Semion Prihodko wrote: > OK, that's my fault. I'm running jitted code on linux x86. > > 2011/11/9 Duncan Sands <baldrick at free.fr> > Hi Semion, > > > In my case the LLVM is built with assertions, but this doesn't

Many VMs focus on performance, optimizations, memory consumption, etc. but very few, if any, focus on fault isolation and security. Given memory safety, any VM reduces to capability security, which is sufficient to implement most security policies of interest; however, most such VMs still ignore two main attack vectors from malicious code: DoS attack on memory allocation, and DoS against the CPU.

OK, that's my fault. I'm running jitted code on linux x86. 2011/11/9 Duncan Sands <baldrick at free.fr> > Hi Semion, > > > In my case the LLVM is built with assertions, but this doesn't help. From >> your >> answer I conclude that thread-local globals are fully implemented in x86 >> JIT. >> > > you didn't mention the JIT. You

Hi Jan, In gcc for Linux, you have the -rdynamic option that allows an executable to dlsym its symbols. Since llvm use dlsym to find the symbols, you could try with this option. That's what I did. And don't forget to use the C++ name if you compile with C++. Cheers, Nicolas Jan Rehders wrote: > Hi, > > I was able to try this on linux again. Unfortunately it doesn't work

Let me cut it down to the core problem: I'm asking about the feasibility of extending LLVM with constructs to manage separate heaps. Given my current understanding of LLVM, I can see this done in two ways: 1. Add heap management instructions to the core instructions, modify allocation routines to explicitly name heaps or modify the runtime to rebind the allocation routines depending on some

Background: We plan to use ORC to JIT compile hot-paths, optimizing them to fully utilize the currently running architecture. To do this, we extract the hot-paths' code section (including external linkages, functions, variables, etc) and embed them into the host program. These embedded information are then pass to orc to be compiled and executed. However, the JIT process may fail and may

Chris Lattner wrote: > On Jan 19, 2009, at 7:55 AM, Andrew Haley wrote: > >> This is x86_64. I have a problem where an absolute memory load >> The current LLVM trunk does not have this bug. This seems quite a >> nasty >> bug; is there any chance of a bug-fix release for LLVM 2.4, or >> should I >> just use LLVM trunk until LLVM 2.5 ? > > As

Hi, I have tried another way: ar rcs libsysdeputil.a sysdeputil.o gccld seems to recognize the file type. However, it stills find unresoved symbols which are actually the functions in sysdeputil.o (can be find out with `nm libsysdeputil.a`) The problem disappears if native gcc/ld tool chain is used. As another test, main.c: ----------------- extern void foo(); int main() { foo(); return

Hi, This is really more a general compiler question, not so specific to LLVM. Given a set of pre-defined "primitive" functions, is there a way to un-inline function calls out of a function? (This is different from "extracting" functions because you are not allowed to create a new function, but only to use existing functions in the pool. These "primitive" functions

I'm just starting to have a look at LLVM, so forgive me if this is a simple question. What I'd like to do is use the JIT api to construct a "program" that calls a series of functions. In other words I'm wanting to translate a scripting language into some executable assembler where each primitive of my scripting language is implemented with a "normal" function.

Hi! I've read in the mailing list archives that LLVM isn't able to run threaded programs: http://mail.cs.uiuc.edu/pipermail/llvmdev/2003-December/000758.html Is there a Bugzilla about this that I could CC myself to? Or should I file one? Cheers //Johan

Torvald Riegel wrote: > On Wednesday 20 February 2008 01:51, Andrew Lenharth wrote: >> Anyone have an idea? The patch as it stands is attached below. X86 >> is a pseudo instruction because the necessary ones and prefixes aren't >> in the code gen yet, but I would imagine they will be (so ignore that >> ugliness). The true ugliness can be seen in the alpha impl

Johan, You are correct that today LLVM doesn't handle multi-threaded programs. However, I believe Misha is working on this now (correct me if I'm wrong Misha). To file a bugzilla on this would be a little redundant. Its a well-known issue and one that is being worked on. Reid. Johan Walles wrote: > Hi! > > I've read in the mailing list archives that LLVM isn't able