[LLVMdev] finalizeObject function implemetation in MCJIT is wrong

Radek Zagorowicz radek.zagorowicz at gmail.com
Wed Nov 19 02:12:00 PST 2014


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>


More information about the llvm-dev mailing list