llvm dev - Nov 2014 - [LLVMdev] finalizeObject function implemetation in MCJIT is wrong

Hi Radek,

Sorry for the delayed response. I haven't had time to check your analysis
yet, but you're probably right: MCJIT's support for multiple modules in
a
single instance is patchy at best.

Do you have a test case (e.g. an lli invocation) that triggers this bug, or
is this something you discovered just by reading the code?

Cheers,
Lang.

On Thu, Nov 13, 2014 at 8:46 AM, David Blaikie <dblaikie at gmail.com>
wrote:
> [+Lang, owner of JITs, defender of register allocators, etc]
>
> On Thu, Nov 13, 2014 at 8:29 AM, Radek Zagorowicz <
> radek.zagorowicz at gmail.com> wrote:
>
>> Hi all.
>>
>> I found some issue in implementation of finalizeObject function in
>> MCJIT.cpp. If you look at the source code of the function, you can
notice
>> that machine code for second "owned" module will never be
generated if it
>> doesn't depend on the first one. More over it will cause a crash if
entry
>> point isn't in first module. Implementation of finalizeObject using
for
>> loop will omit every other module in OwnedModules, because function
>> generateCodeForModule moves module form "added" to
"loaded".
>> Am I right?
>>
>> Regards.
>>
>> rodia
>>
>> _______________________________________________
>> 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/20141118/744395b2/attachment.html>

I will prepare this test case with lli ASAP.

2014-11-18 19:48 GMT+01:00 Lang Hames <lhames at gmail.com>:
> Hi Radek,
>
> Sorry for the delayed response. I haven't had time to check your
analysis
> yet, but you're probably right: MCJIT's support for multiple
modules in a
> single instance is patchy at best.
>
> Do you have a test case (e.g. an lli invocation) that triggers this bug,
> or is this something you discovered just by reading the code?
>
> Cheers,
> Lang.
>
> On Thu, Nov 13, 2014 at 8:46 AM, David Blaikie <dblaikie at
gmail.com> wrote:
>
>> [+Lang, owner of JITs, defender of register allocators, etc]
>>
>> On Thu, Nov 13, 2014 at 8:29 AM, Radek Zagorowicz <
>> radek.zagorowicz at gmail.com> wrote:
>>
>>> Hi all.
>>>
>>> I found some issue in implementation of finalizeObject function in
>>> MCJIT.cpp. If you look at the source code of the function, you can
notice
>>> that machine code for second "owned" module will never be
generated if it
>>> doesn't depend on the first one. More over it will cause a
crash if entry
>>> point isn't in first module. Implementation of finalizeObject
using for
>>> loop will omit every other module in OwnedModules, because function
>>> generateCodeForModule moves module form "added" to
"loaded".
>>> Am I right?
>>>
>>> Regards.
>>>
>>> rodia
>>>
>>> _______________________________________________
>>> 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/20141119/6eb0d5b7/attachment.html>

Hi Lang.

I prepared the test case.
Download file from attachment.
Compile main.cpp and run it. test1.ll and test2.ll should be in the working
folder.
When you uncomment line 49 in main.cpp it starts working fine.

My configuration is:
llvm 3.5
msvc 11 (VS 2012)
architecture x86

Regards.

P.S. After preparing this test case I noticed that this bug is fixed in the
newest implementation of MCJIT in llvm trunk branch. :)


2014-11-19 11:12 GMT+01:00 Radek Zagorowicz <radek.zagorowicz at
gmail.com>:
> I will prepare this test case with lli ASAP.
>
> 2014-11-18 19:48 GMT+01:00 Lang Hames <lhames at gmail.com>:
>
>> Hi Radek,
>>
>> Sorry for the delayed response. I haven't had time to check your
analysis
>> yet, but you're probably right: MCJIT's support for multiple
modules in a
>> single instance is patchy at best.
>>
>> Do you have a test case (e.g. an lli invocation) that triggers this
bug,
>> or is this something you discovered just by reading the code?
>>
>> Cheers,
>> Lang.
>>
>> On Thu, Nov 13, 2014 at 8:46 AM, David Blaikie <dblaikie at
gmail.com>
>> wrote:
>>
>>> [+Lang, owner of JITs, defender of register allocators, etc]
>>>
>>> On Thu, Nov 13, 2014 at 8:29 AM, Radek Zagorowicz <
>>> radek.zagorowicz at gmail.com> wrote:
>>>
>>>> Hi all.
>>>>
>>>> I found some issue in implementation of finalizeObject function
in
>>>> MCJIT.cpp. If you look at the source code of the function, you
can notice
>>>> that machine code for second "owned" module will
never be generated if it
>>>> doesn't depend on the first one. More over it will cause a
crash if entry
>>>> point isn't in first module. Implementation of
finalizeObject using for
>>>> loop will omit every other module in OwnedModules, because
function
>>>> generateCodeForModule moves module form "added" to
"loaded".
>>>> Am I right?
>>>>
>>>> Regards.
>>>>
>>>> rodia
>>>>
>>>> _______________________________________________
>>>> 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/20141120/cf71239d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test2.ll
Type: application/octet-stream
Size: 74 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141120/cf71239d/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test1.ll
Type: application/octet-stream
Size: 79 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141120/cf71239d/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: main.cpp
Type: text/x-c++src
Size: 1523 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141120/cf71239d/attachment.cpp>