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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141113/bdea2e51/attachment.html>

[+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/20141113/ef71e448/attachment.html>

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>