llvm dev - Nov 2013 - [LLVMdev] MCJIT RemoteMemoryManager Failures on ARM

On 26 November 2013 01:55, NAKAMURA Takumi <geek4civic at gmail.com>
wrote:
> IMHO, tests may be suppressed with lit.local.cfg, only if;
>
They were disabled, but then re-enabled because they don't fail on normal
build bots, but they do on self-host bots. So, I think this is a more
serious issue than just MCJIT, I think this is a Clang miscompilation. I'll
try on x86 to see if the self-hosting problem appears.


  - The issue is filed -- PR18057
>   - There is at least one person responsible to watch on this issue.
>
Yes, but without priority, the bug will be forgotten.


I would not help you since I don't have any arm
boxes.
>
I have an ARM box which you can SSH into, if you need. My knowledge of how
the MCJIT should behave is very limited. If you're willing to take a look,
I'd do my best to help you working on ARM.

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131126/420962bd/attachment.html>

I'd be OK with disabled these tests if they can be specifically disabled for
ARM with clang.

The main purpose of these tests is to ensure that none of the
MCJIT/RuntimeDyld/*MemoryManager layering gets rearranged in a way that makes
remote execution impossible.

I would also note that the failure isn't actually in anything
MCJIT-specific.  Aside from the fact that it seems to be clang-specific, the
code that is failing is specific to the lli remote implementation.  It's not
clear to me why it would fail under aggressive optimization with clang, but I
wouldn't characterize that code as particularly robust.

I just updated the bugzilla report with a few comments about the failure.  The
short of it is that there's nothing MCJIT-specific about this failure. 
It's most likely a pipe I/O problem.  I think it's possible that the
clang optimizations are just exposing a timing-related vulnerability in the pipe
handling.

-Andy

From: Renato Golin [mailto:renato.golin at linaro.org]
Sent: Tuesday, November 26, 2013 1:30 AM
To: NAKAMURA Takumi
Cc: Kaylor, Andrew; LLVM Dev
Subject: Re: MCJIT RemoteMemoryManager Failures on ARM

On 26 November 2013 01:55, NAKAMURA Takumi <geek4civic at
gmail.com<mailto:geek4civic at gmail.com>> wrote:
IMHO, tests may be suppressed with lit.local.cfg, only if;

They were disabled, but then re-enabled because they don't fail on normal
build bots, but they do on self-host bots. So, I think this is a more serious
issue than just MCJIT, I think this is a Clang miscompilation. I'll try on
x86 to see if the self-hosting problem appears.


  - The issue is filed -- PR18057
  - There is at least one person responsible to watch on this issue.

Yes, but without priority, the bug will be forgotten.


I would not help you since I don't have any arm boxes.

I have an ARM box which you can SSH into, if you need. My knowledge of how the
MCJIT should behave is very limited. If you're willing to take a look,
I'd do my best to help you working on ARM.

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131126/c76121a1/attachment.html>

On 26 November 2013 19:05, Kaylor, Andrew <andrew.kaylor at intel.com>
wrote:
>  I would also note that the failure isn’t actually in anything
> MCJIT-specific.  Aside from the fact that it seems to be clang-specific,
> the code that is failing is specific to the lli remote implementation.
> It’s not clear to me why it would fail under aggressive optimization with
> clang, but I wouldn’t characterize that code as particularly robust.
>
I agree. I think this is more likely a codegen fault on Clang's side that
crashes the client, not even the remote implementation, that even being
crude, has very little room for failure of that magnitude.


I just updated the bugzilla report with a few comments about the
failure.
> The short of it is that there’s nothing MCJIT-specific about this failure.
> It’s most likely a pipe I/O problem.  I think it’s possible that the clang
> optimizations are just exposing a timing-related vulnerability in the pipe
> handling.
>
Ok, I'll disable those tests for ARM for now and will look into the bug.

I don't know much about how MCJIT works, so creating the reduced test case
will prove difficult. But I'll progress, because I do want MCJIT to work
well on ARM, and disabling tests is the wrong way to head. ;)

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131126/88b09dab/attachment.html>