lli external functions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

lli external functions

Daniel Dunbar
I find the behavior of lli (in --force-interpreter mode) rather strange when calling external
functions. Currently if a function has not been defined in the internal "known external"
function table it just tries to resolve the symbol and cast it to its generic external function
type.

Is this really the intended behavior? This is most likely to cause the interpreter to crash
without warning when it calls the function. The only use case seems to be if a user wants
to explicitly extend the interpreter by providing a loadable module of functions that expect
to be called in this fashion, but that doesn't seem very common (and is undocumented?).
It seems like it would make more sense for the interpreter to just give up and report an
error to the user (or at least give a warning that it is calling into arbitrary binary code).

In any case, it seems like lli should know how to call memmove. Patch attached.

 - Daniel

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

=?utf-8?q?lli-memmove-support.patch?= (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: lli external functions

Evan Cheng-2

On Feb 19, 2008, at 10:44 AM, Daniel Dunbar wrote:

> I find the behavior of lli (in --force-interpreter mode) rather  
> strange when calling external
> functions. Currently if a function has not been defined in the  
> internal "known external"
> function table it just tries to resolve the symbol and cast it to  
> its generic external function
> type.
>
> Is this really the intended behavior? This is most likely to cause  
> the interpreter to crash
> without warning when it calls the function. The only use case seems  
> to be if a user wants
> to explicitly extend the interpreter by providing a loadable module  
> of functions that expect
> to be called in this fashion, but that doesn't seem very common (and  
> is undocumented?).
> It seems like it would make more sense for the interpreter to just  
> give up and report an
> error to the user (or at least give a warning that it is calling  
> into arbitrary binary code).

I think this is the acceptable behavior for an interpreter which does  
not make use of OS facility. Known functions are added on demand.

>
>
> In any case, it seems like lli should know how to call memmove.  
> Patch attached.

Thanks. I'll apply.

Evan

>
>
> - Daniel
> <lli-memmove-
> support.patch>_______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev