[LLVMdev] Possible change to ExecutionEngine::create()

[Daniel Dunbar]

I probably shouldn't have weighed in on this thread, since I have
limited knowledge on the JIT.

If the current behavior is to enumerate all those modules, however,
adding a flag to the constructor doesn't seem so bad -- especially now
that we have the builder. I'll defer to Evan though.

 - Daniel

On Thu, Jul 23, 2009 at 2:10 PM, Rob Grapes<Rob.Grapes at ur.co.nz> wrote:
> Hi Daniel,
>
> In my case ExecutionEngine::create() loads 40 modules, then each time I try to resolve a symbol that I know is in a DLL that I supply, it looks through all 40 modules first.  This is on Windows, so I get the following modules loaded:
>
> ntdll.dll, kernel32.dll, USER32.dll, GDI32.dll, SHELL32.dll, ADVAPI32.dll, RPCRT4.dll,
> Secur32.dll, msvcrt.dll, SHLWAPI.dll, ole32.dll, OLEAUT32.dll, WS2_32.dll, WS2HELP.dll,
> PSAPI.DLL, VERSION.dll, MSACM32.dll, WINMM.dll, WININET.dll, Normaliz.dll, urlmon.dll,
> iertutil.dll, IPHLPAPI.DLL, IMM32.dll, HID.DLL, SETUPAPI.dll, OPENGL32.dll, GLU32.dll,
> DDRAW.dll, DCIMAN32.dll, dbghelp.dll, LPK.DLL, USP10.dll, comctl32.dll, comctl32.dll,
> rsaenh.dll, uxtheme.dll, MSCTF.dll, USERENV.dll, as well as the exe.
>
> It wouldn't be so bad if it looked through the modules in reverse order, so mine were searched
> first.
>
> So, as an alternative can the order be changed, or, can it be set up so that the user must explicitly enumerate and add modules.
>
> Rob.
>
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Daniel Dunbar
> Sent: Thursday, 23 July 2009 6:35 p.m.
> To: LLVM Developers Mailing List
> Subject: Re: [LLVMdev] Possible change to ExecutionEngine::create()
>
> 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
>>
>
> _______________________________________________
> 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
>