similar to: [LLVMdev] What is on the LLVM horizon for truly relocatable JITted code?

This is the only thing that I’ve found that works in terms of getting the exception to propagate out of the JITted function - change the “call” to an “invoke” and hook in the do-nothing landing-pad. https://gist.github.com/drmeister/7a35046f666826206973 Compare line 646 of the file above to the one that I just posted. > https://gist.github.com/drmeister/b97dec956c6ee9ffeb75 The first one

Logan, How would I dump the object file generated by the JIT compiler pipeline? Could you point me to an example of how something like that is done? I’m used to working with the JIT machinery in memory but not writing object files out to disk. I’m have code to generate object files for AOT compilation - is it done the same way? Best, .Chris. On Apr 12, 2015, at 2:27 PM, Logan Chien

Is it possible to inline functions compiled from C++ code into generated code that is fed, Module by Module, into the ORC JIT? I'd like to add a Module compiled from C++ code into the JIT and then as I add later modules, functions from the first module are inlined in the later ones. I already do this for file compilation/linking in my Common Lisp compiler “Clasp” (github.com/drmeister/clasp

Logan, I need to make a correction of the post that preceded this one! I was wrong when I said this: > When I load the bitcode file for this module and then dump it just before it is JITted, the “uwtable” attribute has disappeared - is this prune-eh doing its work even though it’s not listed above in the list of function pass managers? The “uwtable” attribute does not disappear! I had

Hi Christian, Thanks for your explanation. I know your situation now. I would suggest you to check the optimization pass used by the JIT compiler, especially IPO/PruneEH.cpp. It will try to add nounwind attribute to functions which will result in the problem you have mentioned earlier. Alternatively, as a workaround, try to add uwtable (function attribute) to the functions that are generated

I upgraded my versions of llvm, clang and compiler-rt to the top-of-tree versions from last night (r180162, April 24). I recompiled debug versions of llvm, clang and my code. I then regenerated my test case and the results were the same - I can list lines of dwarf1.lsp in lldb but I can't set break-points or do anything else (what else should I be able to do?). The updated file that

> On 2015-Jan-19, at 12:38, Frédéric Riss <friss at apple.com> wrote: > > >> On Jan 19, 2015, at 12:04 PM, Christian Schafmeister <chris.schaf at verizon.net> wrote: >> >> >> I forgot to mention this in my initial email. >> >> The build of LLVM that I was using was commit a0d5d7aed8e177cea381b3d054d80c212ece9f2c >> The date on the

I forgot to mention this in my initial email. The build of LLVM that I was using was commit a0d5d7aed8e177cea381b3d054d80c212ece9f2c The date on the commit is: Date: Fri Sep 26 12:34:06 2014 Also: Today I grabbed the ToT llvm/clang/clang-extra-tools and I’m working on getting my code to be compatible with it. I can switch back and forth between the current ToT llvm and the old one. Thanks,

Correct or no I don't know, but this change will affect all x86-64 targets including Linux and Windows as getMaxStubSize() is called from the ELF linker as well as the Mach-O linker. 2013/10/15 Christian Schafmeister <chris.schaf at verizon.net> > > With the help of iain at codesourcery.com and andrew.kaylor at intel.com we > tracked the problem down to a bad relocation that

One other thing that may or may not illuminate the situation. When I run under gdb (on OS X 10.8.3 this is an ancient version of gdb 6.3.5 - but it works with clang compiled C++ code) I get the following error when I try to list a line in dwarf1.lsp: Dwarf Error: Cannot handle DW_FORM_<unknown> in DWARF reader [in module /Users/meister/Development/cando/src/tests/core/dwarf1.bundle] (gdb)

Hello, I wonder if someone would know what is going on below. All of a sudden I’m getting this assertion thrown: Assertion failed: (New->getType() == getType() && "replaceAllUses of value with new value of different type!"), function replaceAllUsesWith, file /Users/meister/Development/externals-clasp/llvm36/lib/IR/Value.cpp, line 345. It’s happening when

Hi Christian, > I don’t see anything in the Itanium ABI that says I need to call the function that throws an exception with “invoke” to get exception handling to work! AFAICT, it is the design of LLVM IR and its implementation. To catch the exceptions thrown by the callee functions, we should use the invoke instruction along with the landingpad instruction. If you are calling a function

Do the LLVM Setjmp/Longjmp intrinsics interact with C++ exception handling and execute C++ cleanup actions? I compiled a small example using setjmp/longjmp using clang and they did not execute C++ cleanup actions and calling longjmp bypassed calling destructors on objects that were allocated between the call to setjmp and longjmp. I’m wondering if the LLVM intrinsics behave differently from

Hi Christian Your use case seems to have similar requirements as remote JITing in ORC. So far I haven't used that part myself and I am sure Lang can tell you much more about it. However, this comment on the RemoteObjectClientLayer class sounds promising for your questions (1) and (2): /// Sending relocatable objects to the server (rather than fully relocated /// bits) allows JIT'd code

Yes, you are correct Yaron. Before we commit this we ought to put a check in to see what the target OS is. I just suggested the change below as a quick and easy way to verify that this was the cause of the problem. I'll clean it up. -Andy From: Yaron Keren [mailto:yaron.keren at gmail.com] Sent: Monday, October 14, 2013 9:09 PM To: Christian Schafmeister; Kaylor, Andrew; iain at

Hey folks, I'm wrestling with adding DWARF source code file/line information to my generated LLVM-IR from my Common Lisp compiler. I think I'm doing everything properly using the llvm::DIBuilder class - but when I load my Common Lisp application and load a compiled bundle into it I don't seem to be able to access the metadata properly. I can list source lines using "l -f

If I spoke incorrectly about what systems this problem/change effects I apologize. I'll leave it to Andrew to determine that. Best, .Chris. "Kaylor, Andrew" <andrew.kaylor at intel.com> writes: > Yes, you are correct Yaron.  Before we commit this we ought to put a > check in to see what the target OS is.  I just suggested the change > below as a quick and easy way

I didn't make it clear that I load my Common Lisp application into "lldb" and then load a compiled bundle into my application using dlopen (I'm on OS X and I'm generating a kind of shared library called a "bundle"). Once everything is loaded, the functions from the bundle are accessible to my Common Lisp environment but I don't seem to be able to access the

Hmm, are you using a version of LLVM with asserts enabled (I.e. A debug build)? I cut-and-paste your IR into a text file and ran (a debug version of) llc on it, which caused the following assertion failure that seems related to some DWARF mishap: llc: ../lib/CodeGen/AsmPrinter/DwarfDebug.cpp:1400: void llvm::DwarfDebug::beginFunction(const llvm::MachineFunction*): Assertion `TheCU &&