similar to: [LLVMdev] make update (svn info) does not follow links

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

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

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

2010/1/11 Garrison Venn <gvenn.cfe.dev at gmail.com> > I have not tried this, but a linkage type of PrivateLinkage would not add > to the symbol table according > to the doc. > > LLVMSetLinkage(g, LLVMPrivateLinkage); > Thanks - I hadn't thought of that. > > Garrison > > On Jan 11, 2010, at 14:03, James Williams wrote: > > 2010/1/11 Eli Friedman

Unfortunately, the current gdb support doesn't include line numbers. It'll tell you what function it crashed in and the stack trace though. Line numbers will probably come when the llvm-mc project is merged into the JIT. On Tue, Feb 9, 2010 at 9:37 AM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > Are you running this in a JIT? If so this will help:

Garrison Venn wrote: > Just wanted to note that this morning that I had to (for a complete, including examples, build): > > 1) Move llvm/cmake/modules/LLVMLibDeps.cmake.old out of way for svn update to work > 2) Modfiy llvm/examples/Makefile to remove TracingBrainF in order for a subsequent make to work > > Don't know if the current repository changes will fix this, or if

Eek! I'm going to lose track of the threads if you start a new one every time you update the patch. Consider using http://codereview.appspot.com/? On Fri, Feb 26, 2010 at 5:44 PM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > Hey all, > Attached you will find an experimental patch which allows me to play with a > derived JIT class. With this patch > I've alleviated

On Fri, Jan 8, 2010 at 12:12 PM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > I just added an exception example to the wiki intended to be run in a JIT environment. Although this information is heavily date dependent, > as the LLVM exception subsystem will be modified as time goes on, I could have used such an example when I was looking into this; hence the submission. >