Ok I need and want native performance - it's a scientific application and although very complex things will be referred to the core methods I cannot stop users from writing large loops and complain about the performance. In the worst case they crash the whole thing ... but I'm willing to take that risk :D.<br>
<br>Now concerning your answer I do not see how it might help me. If I understand it correctly you have implemented a way to get information about the Decl of jitted methods. Now how does that help me, because I still think I need to declare the mangled names to the JIT, and for this purpose I need to now them at compile time of the host application. <br>
<br>thx,Frank<br><br><div class="gmail_quote">2010/7/16 John McCall <span dir="ltr"><<a href="mailto:rjmccall@apple.com">rjmccall@apple.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Jul 15, 2010, at 11:20 PM, Frank Fuchs wrote:<br>
> Well if I understand your view on it correctly then ... yes that is what I'm trying to do. However, please allow me to give a more long winded description of what I want to do. So I have a rather large Qt/C++ application and I want to give it some scripting powers (make its computational core scriptable from within the application itself). I first tried to embed some script language (QtScript and Chaiscript), but they did not convince me in terms of their features and performance (although I must say that I liked both approaches anyway). Now I want to embed clang into my application to execute small C++ scripts/ user supplied methods. In the examples for clang there is an app for that ;),  well almost. The clang-interpreter example takes C/C++ code compiles and runs it. Now the "only" thing I have to do is to enhance it by exposing my host application methods to the jitted user supplied scripts. It can be done by either wrapping all of my methods in extern "C" functions. But this is not what I want.<br>

> If I drop the extern "C" and use C++ headers instead I get error messages like "LLVM error: program used external function '_Z10testCallerv()' which could not be resolved". Of course it could not be resolved ... since I was not able/willing to guess the name-mangling while declaring the the external function to the clang-interpreter. I used declared "void testCaller()". Now if I change my declaration to the mangled name it works. I can call C++ methods which reside in the host-application from my scripts. However, I do not want to mangle all the names of my to-be exposed functions by hand. There must be a method for that as well - clang must have it already.<br>

<br>
</div>I actually recently introduced a hack to support this sort of in-process JITting (to support LLDB, which does something similar).  It's not at all documented, and (like most of Clang's APIs) it's subject to change at a whim, but it's probably easier than repeatedly mangling things.  When setting up your environment, set the EmitDeclMetadata flag on the CodeGenOpts.  After compilation, the module will have a named metadata called "clang.global.decl.ptrs"; each of the operands of that will be a ConstantStruct containing a GlobalValue and a ConstantInt whose value can be casted to Decl*.  Not the prettiest interface imaginable, but it's there.<br>

<br>
That said, I would really recommend Lua if you're looking for an embedded scripting language and you don't need native-code performance.  It's a *lot* safer than letting users run arbitrary C++ code within your process.<br>

<font color="#888888"><br>
John.</font></blockquote></div><br>