I'm back working on my threading patch for the LLVM JIT after being distracted by a paper deadline. I think I have things working nicely on Mac OS X (I just did a CVS up and it will take another hour or two to build), but I'm having an issue with building on Linux. Specifically, "lli" fails to link because it now needs to link against libpthread, because it ends up pulling in ExecutionEngine.h which in turn pulls in ThreadSupport.h. I'm wondering how this should be fixed, because I'm afraid it may not be a simple problem. So the first question is, to which Makefile do I need to add the "-lpthread" flag to get the thing to compile? The next issue is what is the *right* way to do this: 1. Some platforms (eg. Mac OS X) don't need to specify "-lpthread" because pthreads is included in the base libc (thankfully, on Mac OS X it doesn't hurt if you do). Other platforms need to pull in some other thread library entirely (Windows). Some platforms may not HAVE pthreads, or may have a broken version. This suggests that this likely has to be part of the autoconf magic which I do not understand. 2. The interpreter probably does not need thread support at all, since it is almost certainly thread unsafe. Maybe it should override the "platform" version of ThreadSupport and with a null implementation. Alternatively, perhaps ExecutionEngine.h should not pull in ThreadSupport, and only JIT.h should. Any suggestions for the correct direction out of this situation? Thanks, Evan Jones
On Tue, 15 Mar 2005, Evan Jones wrote:> I'm back working on my threading patch for the LLVM JIT after being > distracted by a paper deadline. I think I have things working nicely on Mac > OS X (I just did a CVS up and it will take another hour or two to build), but > I'm having an issue with building on Linux. Specifically, "lli" fails to link > because it now needs to link against libpthread, because it ends up pulling > in ExecutionEngine.h which in turn pulls in ThreadSupport.h. I'm wondering > how this should be fixed, because I'm afraid it may not be a simple problem.Ah, ok.> So the first question is, to which Makefile do I need to add the "-lpthread" > flag to get the thing to compile? The next issue is what is the *right* way > to do this:I think the answer is some form of: 1. The platform specific flag (e.g. -lpthread) should go into Makefile.config, named something like THREADS_LINKOPTS. This should obviously be autoconf'd. 2. In Makefile.rules at about line 800, we handle linking tools that use the JIT. This would be a natural place to add THREADS_LINKOPTS to the link arguments (e.g. like "-dlopen self" is added). It's not clear to me if pthreads will be required just by the JIT-using-tools, or if it will be required by everything. If you have thread-support stuff going into lib/Support, all llvm tools should be linked to libpthread. With all of the above said, I'm no longer the llvm build system guru, so I'll defer to Reid to make any comments and corrections on the above advice. :) In particular, I don't know the appropriate way to autoconf this, though I'm sure there is some standard way to do it.> 2. The interpreter probably does not need thread support at all, since it is > almost certainly thread unsafe. Maybe it should override the "platform" > version of ThreadSupport and with a null implementation. Alternatively, > perhaps ExecutionEngine.h should not pull in ThreadSupport, and only JIT.h > should.I think that ideally eventually the interpreter should support threads as well, but it's not worth actually doing the work now, so I wouldn't worry about it. -Chris -- http://nondot.org/sabre/ http://llvm.cs.uiuc.edu/
On Mar 16, 2005, at 12:01, Chris Lattner wrote:> It's not clear to me if pthreads will be required just by the > JIT-using-tools, or if it will be required by everything. If you have > thread-support stuff going into lib/Support, all llvm tools should be > linked to libpthread.Well, at the moment, I've added a mutex to ExecutionEngine. Thus, anything that pulls in this class needs thread support. After using grep, it seems like the only thing besides the JIT is the interpreter. Linking all the llvm tools with pthreads would be overkill, but it certainly won't hurt too much, except wasting a bit of virtual memory. At any rate, I've got a hack now that works, and I'll worry about the exact details a bit later (or maybe let someone else worry about the exact details later?).> In particular, I don't know the appropriate way to autoconf this, > though I'm sure there is some standard way to do it.Right. I've found a couple of pthreads autoconf macros but the systems I have access to all have autoconf 2.57, not 2.59. Ergh. I'm not going to worry about autoconf for now, but I'll see if I can find a more up to date.> I think that ideally eventually the interpreter should support threads > as well, but it's not worth actually doing the work now, so I wouldn't > worry about it.Hmm... I can see that might be a bit of a challenge, particularly if the interpreter can call out to native code, and be called by native code. It would definitely involve using thread local storage for the per thread interpreter state. I'm definitely not going to worry about that, but it certainly does mean that I won't feel bad pulling in pthreads as a dependency. Evan Jones