[LLVMdev] fastcc and ExecutionEngine::getPointerToFunction()

[OvermindDL1]

Er... Sending this to the list instead of the parent...

On Thu, Nov 19, 2009 at 4:49 AM, Hans Wennborg <hans at hanshq.net> wrote:
> Yesterday I realised that if a Function has the calling convention set
> to "fast", then it is a bad idea to call it through the function pointer
> one gets from ExecutionEngine::getPointerToFunction().
>
> The problem is that when calling it from my C++ program, the call will
> be made C-style, while the function expects to be called the fastcc way.
>
> Could LLVM either warn the user of this, or solve it for the user?
>
> One approach would be that getPointerToFunction() asserts that the
> function has default calling convention. This way, the user would be
> alerted.
>
> Another approach would be that if getPointerToFunction() detects that
> the function does not have default calling convention, it produces a
> wrapper function, and returns a pointer to that.
>
> My question is, is there code that would get into trouble because of
> this?
>
> For example, someone who is aware of this might be doing inline asm to
> produce a fastcc call through the pointer.
>
> Or, someone might rely on the function actually being located on the
> returned address, and not necessarily calling it. This would break if
> the address to the wrapper is returned instead.
>
> Any thoughts on this?
>
> On a side note: wouldn't it be nice if the VerifierPass checks that
> calling conventions on calls and functions in a module match up?

I would prefer them to remain fastcc if I specify them as fastcc as I
actually do have 'event' handlers passed as fastcc to my C++ code
before being passed back into the JIT as another function parameter so
it can call it as fastcc internally.  If someone is getting a pointer
to a function, they should know about calling conventions anyway.