[LLVMdev] Possible change to ExecutionEngine::create()
Daniel Dunbar
daniel at zuster.org
Wed Jul 22 23:34:56 PDT 2009
Hi Rob,
Can you comment on exactly what the problem is you want to solve? Is
it a performance issue with LoadLibraryPermanently, or do you simply
not want the external symbols to be resolved from within the JIT?
- Daniel
On Wed, Jul 22, 2009 at 11:22 PM, Evan Cheng<evan.cheng at apple.com> wrote:
>
> On Jul 22, 2009, at 9:43 PM, Rob Grapes wrote:
>
>> Hi,
>>
>> Would it be possible to make the following slight change to
>> ExecutionEngine::create()?
>>
>> I would like to be able to disable the automatic enumeration of
>> loaded modules, and the subsequent searching for undefined symbols
>> (using SearchForAddressOfSymbol).
>>
>> I propose adding an extra parameter to the function definition,
>> defaulting to true.
>
> I'd rather not. The current API is messy enough already. Is there not
> another way to solve the problem?
>
> Evan
>
>>
>> static ExecutionEngine *create(ModuleProvider *MP,
>> bool ForceInterpreter = false,
>> std::string *ErrorStr = 0,
>> bool Fast = false,
>> bool EnumModules = true);
>>
>> And corresponding change to the function.
>>
>> ExecutionEngine *ExecutionEngine::create(ModuleProvider *MP,
>> bool ForceInterpreter,
>> std::string *ErrorStr,
>> bool Fast,
>> bool EnumModules) {
>> ExecutionEngine *EE = 0;
>> if (EnumModules) {
>> // Make sure we can resolve symbols in the program as well. The
>> zero arg
>> // to the function tells DynamicLibrary to load the program, not
>> a library.
>> if (sys::DynamicLibrary::LoadLibraryPermanently(0, ErrorStr))
>> return 0;
>> }
>> ...
>>
>> Your help would be appreciated.
>>
>> Rob.
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
More information about the llvm-dev
mailing list