similar to: [LLVMdev] Unable to schedule 'Dominator Tree Construction'?

Hi Mondi, maybe: don't link your dynamic library against the LLVM libraries. If the tool you load it into is already linked against them (like the opt tool is) then global constructors will be run twice (once when your tool is started and once when the dynamic library is loaded) and strange things will happen. Ciao, Duncan. On 26/07/12 22:27, mondi wrote: > I have a simple parser / JIT

I have a simple parser / JIT execution module which I recently split up into separate shared libraries. Previously, and as a test case, I'd generate IR, and immediately reparse / execute it. Now, the execution step lives in a separate but linked shared library. As soon as this happened, this error start popping up: Unable to schedule 'Dominator Tree Construction' required by

Thanks for the response. Since X11 is by default installed on OS X when the developer tools are installed. Running autoconf fixed the issue with configure not finding X11, although I did not check why the configure script did not have the correct path (I'm assuming this was the case). Next I'm on to the gtk+ dependencies which I'm going to try to solve with macports if I have to. I

On Tue, Nov 22, 2011 at 11:32 AM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > As directed from http://vmkit.llvm.org/get_started.html, I'm getting: > > checking for ld used by GCC... /usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld > checking if the linker (/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld) is GNU ld... no > checking for shared

As directed from http://vmkit.llvm.org/get_started.html, I'm getting: checking for ld used by GCC... /usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld checking if the linker (/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld) is GNU ld... no checking for shared library run path origin... /bin/sh: ./config.rpath: No such file or directory done checking for iconv... yes

I think so. It also fails the same way on LLVM trunk from last week. The full backtrace is below. It appears that frame #3 is a compilation of __l_personality() and frame #14 is a compilation of f(). The compilation of __l_personality appears to have been triggered by the need to output DWARF information for f(). -- James #0 0x00007ffff6ed84b5 in *__GI_raise (sig=<value optimised out>) at

Interesting. Was this the reason you were getting the recursive compilation error in JIT::runJITOnFunctionUnlocked(...) (isAlreadyCodeGenerating)? Do you have the time to try your test with 2.7? Garrison On Jan 22, 2010, at 17:37, James Williams wrote: > I've worked around this issue in my test case by simply calling my personality function on program to ensure it's JIT'ed

Kenneth Uildriks wrote: > On Sun, Jan 10, 2010 at 12:38 PM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > > Won't passing llvm::Function* around vs strings (function names), also work, at code generation time, > > without the need for a module A dec to module B impl. mapping? > > > > Garrison > > Nope. You cannot place a call instruction into one

I've worked around this issue in my test case by simply calling my personality function on program to ensure it's JIT'ed before any unwind happens. -- James 2010/1/22 Garrison Venn <gvenn.cfe.dev at gmail.com> > No, there is no magic. :-) > > To me though, the tools are magic, because I have no clue what they are > doing without looking at them and using them. >

On Sun, Jan 10, 2010 at 12:38 PM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > Won't passing llvm::Function* around vs strings (function names), also work, at code generation time, > without the need for a module A dec to module B impl. mapping? > > Garrison Nope. You cannot place a call instruction into one module whose callee is a Function from another module. You

Hi James, Just wanted to update you. As you implied the problem here is that the personality function has to be jitted before the code that contains the corresponding llvm.eh.selector intrinsic instruction is jitted. I verified this by creating a generated version of the personality function which unless I jitted first, gave me the same error when running the code. Since you are using tools

No problem I'll drop this from our discussion as it really is only germane to my learning path and imagination. :-) I do at this time still have this concern of allowing a user (developer) the right to turn this "cross module linkage" off, but I'm still in the process of understanding your previous comments on this. Thanks again for the help and time by the way. Garrison PS:

Hi Eli So I found this in Attributes.h: const Attributes UWTable = 1<<30; ///< Function must be in a unwind ///table What does this mean? In particular what does it mean not to add this as a function attribute to a function? I'm obviously going down the wrong road in my interpretation, as I

No, there is no magic. :-) To me though, the tools are magic, because I have no clue what they are doing without looking at them and using them. As their function is not germane to my current endeavors, I hope to learn about them from this list, and most likely from your postings. I know it is a common approach, but to me I think bitcode generation to JIT runtime is a a cool feature of LLVM.

Sorry to keep this thread alive, but I'm learning so ... There is more. The doc for GlobalValue::LinkageTypes or the C API LLVMLinkage is not as clear as the lang ref manual. See: http://llvm.org/docs/LangRef.html#linkage. I'm pointing this out because something like LinkerPrivateLinkage (LLVMLinkerPrivateLinkage), or another one, might be more appropriate to your throw away use case (if

Hi Jeffrey, On Feb 26, 2010, at 16:02, Jeffrey Yasskin wrote: > [sidenote: Please try to avoid extraneous whitespace and line wrapping changes in your patches. It makes it harder to see what you're actually changing] Sorry just saw some preexisting code was not in 80 columns. > > On Fri, Feb 26, 2010 at 4:57 AM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > Hi

If the powers at be want this, I could easily transform the source to the LLVM coding standards, and add the necessary portable UNIX support--someone else would have to add non-UNIX support although the System library probably helps with this. However I'm guessing the LLVM release flux of the exception system, along with a lack of universal platform, dwarf JIT support might be a hinderance in

On Sat, Jul 23, 2011 at 2:36 AM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > Hi Bill, > > Thanks for working on this. > > Is there a reference for the function attribute uwtable, or is it to be defined as > part of this effort? It already exists; there's some limited documentation in the LLVM source, but Rafael apparently forgot to add it to LangRef... -Eli

[sidenote: Please try to avoid extraneous whitespace and line wrapping changes in your patches. It makes it harder to see what you're actually changing] On Fri, Feb 26, 2010 at 4:57 AM, Garrison Venn <gvenn.cfe.dev at gmail.com>wrote: > Hi Olivier, > > On Feb 25, 2010, at 14:10, Olivier Meurant wrote: > > Hi Garrison, > > I finally come back from holidays and take

Hi! If a pass is required then it makes sense to getAnalysis<DwarfWriter>(). getAnalysisIfAvailable<>() is used for cases where a pass want to take advantage of (or fix up) info only *if* it is available. If you prepare a patch to fix getAnalysisifAvailable<>() uses (e.g. DwarfWriter requests you mention below) then I'll apply it. - Devang On Tue, Dec 8, 2009 at 11:11