llvm dev - Nov 2013 - [LLVMdev] [Proposal] Adding callback mechanism to Execution Engines

Hi Andrew,

I used the latest code from trunk. GlobalSymbolTable is being used in
MCJIT.

I guess it wasn't clear from the proposal that the user program will be
modified to indicate that the callback should happen at that point in the
code. The objective is to call some of the functions which belong to lli or
the ExecutionEngine.

Thanks,
Sumeeth


On Fri, Nov 1, 2013 at 5:40 PM, Kaylor, Andrew <andrew.kaylor at
intel.com>wrote:
>  Are you using the latest code from trunk?  I didn’t think the latest
> code used the address mapping in the ExecutionEngine base class.****
>
> ** **
>
> Of course, if people are depending on this it might be something that
> should be fixed if it isn’t working.****
>
> ** **
>
> -Andy****
>
> ** **
>
> *From:* Caldarale, Charles R [mailto:Chuck.Caldarale at unisys.com]
> *Sent:* Friday, November 01, 2013 10:54 AM
> *To:* Kaylor, Andrew; sumeeth kc; LLVM Dev
> *Subject:* RE: [LLVMdev] [Proposal] Adding callback mechanism to
> Execution Engines****
>
> ** **
>
> > *From:* llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu<llvmdev-bounces at cs.uiuc.edu>]
> ****
>
> > *On Behalf Of *Kaylor, Andrew
> > *Subject:* Re: [LLVMdev] [Proposal] Adding callback mechanism to
> Execution Engines****
>
> ** **
>
> > If the function is in a statically linked module, you need to do
> something to explicitly expose it.  With ****
>
> > the older JIT engine you can use addGlobalMapping as Yaron suggests,
> but I don’t think that will work****
>
> > with MCJIT.****
>
> ** **
>
> Seems to work fine for us with MCJIT.****
>
> ** **
>
> - Chuck****
>
> ** **
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131101/7053b4df/attachment.html>

Unless I'm missing something, indeed addGlobalMapping should not work with
MCJIT.
MCJIT does not consult EEState.getGlobalAddressMap when resolving symbols.
Instead it uses RTDyldMemoryManager::getSymbolAddress which checks
with DynamicLibrary::SearchForAddressOfSymbol, so Andy's suggestion of
DynamicLibrary::addSymbol is better as it should work with both JIT and
MCJIT.

Another options is to use the LazyFunctionCreator which is implemented in
both JIT and MCJIT.

Andy - MCJIT::getPointerToFunction does call EE:addGlobalMapping - however
EEState.getGlobalAddressMap is not used in MCJIT. Should this call be
removed?

Yaron



2013/11/1 sumeeth kc <sumeethkc at gmail.com>
> Hi Andrew,
>
> I used the latest code from trunk. GlobalSymbolTable is being used in
> MCJIT.
>
> I guess it wasn't clear from the proposal that the user program will be
> modified to indicate that the callback should happen at that point in the
> code. The objective is to call some of the functions which belong to lli or
> the ExecutionEngine.
>
> Thanks,
> Sumeeth
>
>
> On Fri, Nov 1, 2013 at 5:40 PM, Kaylor, Andrew <andrew.kaylor at
intel.com>wrote:
>
>>  Are you using the latest code from trunk?  I didn’t think the latest
>> code used the address mapping in the ExecutionEngine base class.****
>>
>> ** **
>>
>> Of course, if people are depending on this it might be something that
>> should be fixed if it isn’t working.****
>>
>> ** **
>>
>> -Andy****
>>
>> ** **
>>
>> *From:* Caldarale, Charles R [mailto:Chuck.Caldarale at unisys.com]
>> *Sent:* Friday, November 01, 2013 10:54 AM
>> *To:* Kaylor, Andrew; sumeeth kc; LLVM Dev
>> *Subject:* RE: [LLVMdev] [Proposal] Adding callback mechanism to
>> Execution Engines****
>>
>> ** **
>>
>> > *From:* llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu<llvmdev-bounces at cs.uiuc.edu>]
>> ****
>>
>> > *On Behalf Of *Kaylor, Andrew
>> > *Subject:* Re: [LLVMdev] [Proposal] Adding callback mechanism to
>> Execution Engines****
>>
>> ** **
>>
>> > If the function is in a statically linked module, you need to do
>> something to explicitly expose it.  With ****
>>
>> > the older JIT engine you can use addGlobalMapping as Yaron
suggests,
>> but I don’t think that will work****
>>
>> > with MCJIT.****
>>
>> ** **
>>
>> Seems to work fine for us with MCJIT.****
>>
>> ** **
>>
>> - Chuck****
>>
>> ** **
>>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131102/4f7c1584/attachment.html>

Yes, MCJIT uses the RTDyldMemoryManager::getSymbolAddress when resolving
symbols. I am using the LinkingMemoryManager::getSymbolAddress to resolve
the symbol.

-Sumeeth


On Fri, Nov 1, 2013 at 6:05 PM, Yaron Keren <yaron.keren at gmail.com>
wrote:
> Unless I'm missing something, indeed addGlobalMapping should not work
with
> MCJIT.
> MCJIT does not consult EEState.getGlobalAddressMap when resolving symbols.
> Instead it uses RTDyldMemoryManager::getSymbolAddress which checks
> with DynamicLibrary::SearchForAddressOfSymbol, so Andy's suggestion of
> DynamicLibrary::addSymbol is better as it should work with both JIT and
> MCJIT.
>
> Another options is to use the LazyFunctionCreator which is implemented in
> both JIT and MCJIT.
>
> Andy - MCJIT::getPointerToFunction does call EE:addGlobalMapping - however
> EEState.getGlobalAddressMap is not used in MCJIT. Should this call be
> removed?
>
> Yaron
>
>
>
> 2013/11/1 sumeeth kc <sumeethkc at gmail.com>
>
>> Hi Andrew,
>>
>> I used the latest code from trunk. GlobalSymbolTable is being used in
>> MCJIT.
>>
>> I guess it wasn't clear from the proposal that the user program
will be
>> modified to indicate that the callback should happen at that point in
the
>> code. The objective is to call some of the functions which belong to
lli or
>> the ExecutionEngine.
>>
>> Thanks,
>> Sumeeth
>>
>>
>> On Fri, Nov 1, 2013 at 5:40 PM, Kaylor, Andrew <andrew.kaylor at
intel.com>wrote:
>>
>>>  Are you using the latest code from trunk?  I didn’t think the
latest
>>> code used the address mapping in the ExecutionEngine base
class.****
>>>
>>> ** **
>>>
>>> Of course, if people are depending on this it might be something
that
>>> should be fixed if it isn’t working.****
>>>
>>> ** **
>>>
>>> -Andy****
>>>
>>> ** **
>>>
>>> *From:* Caldarale, Charles R [mailto:Chuck.Caldarale at unisys.com]
>>> *Sent:* Friday, November 01, 2013 10:54 AM
>>> *To:* Kaylor, Andrew; sumeeth kc; LLVM Dev
>>> *Subject:* RE: [LLVMdev] [Proposal] Adding callback mechanism to
>>> Execution Engines****
>>>
>>> ** **
>>>
>>> > *From:* llvmdev-bounces at cs.uiuc.edu [
>>> mailto:llvmdev-bounces at cs.uiuc.edu <llvmdev-bounces at
cs.uiuc.edu>] ****
>>>
>>> > *On Behalf Of *Kaylor, Andrew
>>> > *Subject:* Re: [LLVMdev] [Proposal] Adding callback mechanism
to
>>> Execution Engines****
>>>
>>> ** **
>>>
>>> > If the function is in a statically linked module, you need to
do
>>> something to explicitly expose it.  With ****
>>>
>>> > the older JIT engine you can use addGlobalMapping as Yaron
suggests,
>>> but I don’t think that will work****
>>>
>>> > with MCJIT.****
>>>
>>> ** **
>>>
>>> Seems to work fine for us with MCJIT.****
>>>
>>> ** **
>>>
>>> - Chuck****
>>>
>>> ** **
>>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131101/c04b69e1/attachment.html>