Linux/ARM: Bus error with -O3 flag of clang/llvm-3.6 while running unit-test of .NET Core

Thu Jul 7 00:26:52 PDT 2016

Dear Renato Golin,

I am sorry for late reply because of the long vacation.

Recently, I have got a strange phenomenon about this issue between real
target device and our own linux/arm emulator.

We cannot execute some unit tests on real target device (e.g., raspberry
Pi2 board , ARM Chromebook )

However, we can always execute some unit tests tests on linux/arm emulator.

* linux/arm emulator - https://github.com/dotnet/coreclr/issues/3805

If you already have a similar experience like below case, Could you share
me that?

For example,

1. on linux/arm emulator

arm at emul#> ./corerun  /nfs/common/CompEx/CompEx.exe

Beginning test case CompareExchange(Int64&,Int64,Int64) at 16. 7. 7. 오전
5:52:51

Random seed: 20010415; set environment variable CORECLR_SEED to this value
to repro

Beginning scenario: CompareExchange(0,1,0)

BEFORE: T(0) NI(0) NV(1) I(0)

AFTER: T(1) NI(0) NV(1) I(0)

BEFORE: T(1) NI(0) NV(2) I(1)

AFTER: T(2) NI(1) NV(2) I(1)

Ending test case at 16. 7. 7. 오전 5:52:52

PASS

2. on real target device

root at target:/unit-test/runtime-arm-u1404-release-mode-20160707.2# ./corerun
 /unit-test/common/CompEx/CompEx.exe

Bus error

Below is kernel log messages in case of the real target device.
[91909.525677] Alignment trap: not handling instruction ed940b00 at
[<b21db3d2>]
[91909.525747] Unhandled fault: alignment exception (0x011) at 0xb1f7e3e3
[91909.527989] pgd = ed1e4000
[91909.530218] [b1f7e3e3] *pgd=58d53835, *pte=76bd77df, *ppte=76bd7e7f
[91909.532890] Alignment trap: not handling instruction ed940b00 at
[<b21db3d2>]
[91909.535146] Unhandled fault: alignment exception (0x011) at 0xb1f7e3f5
[91909.537402] pgd = ed1e4000
[91909.539628] [b1f7e3f5] *pgd=58d53835, *pte=76bd77df, *ppte=76bd7e7f

BRs,

Geunsik Lim.
On Jun 21, 2016 12:49 AM, "Renato Golin" <renato.golin at linaro.org> wrote:

> On 20 June 2016 at 15:47, Geunsik Lim <leemgs at gmail.com> wrote:
> > Actually, there are a lot of files from the DotNet Core run-time (e.g.
> > CoreCLR).
> > In this case, How do we reproduce related IRs with upstream 'llc'
> command?
>
> It depends. If the IR your front-end generate strictly follows the
> Language Reference [1], then it's very simple (see below). If not,
> than it can be very hard and we may not be able to help you at all. :/
>
> If it does...
>
> 1. Reduce the C# code to the smallest code that reproduces the error.
>
> In C++, I normally generate a pre-processed file and use that to
> reduce (since the reducer has access to the entirety of the source). I
> assume there is something similar in C#
>
> To reduce the size of the pre-processed file, I use creduce [2], but I
> have no idea how to do it in C#. Before creduce I used to do that
> manually, and I could clean up large amounts of useless stuff by
> removing code and looking for "unused" warnings.
>
>
> 2. Generate IR
>
> Once you have a small enough sample, make sure it reproduces the
> original case. I'm also assuming your front-end can easily generate IR
> that can be consumed by LLVM as if it was passed directly (ie. no
> additional settings that influence code-gen other than what's in the
> IR or can be set via llc). If the IR is still big, you may still try
> to reduce it using bugpoint [3,4,5]. I'm not very familiar with it
> (though I really should), but it's supposed to work similar to creduce
> (among other things). Give it a shot.
>
> Once you have the IR, make sure your version of llc (if you have one)
> can still reproduce the problem and record the options you have used
> (something similar to "-triple thumbv7a-linux-gnueabihf -mfpu=vfpv3").
> Once you can reliably repeat the problem with your llc, try it with
> upstream's llc (recent 3.9-trunk). Fiddle with the parameters if you
> do pass them differently on your own toolchain, until you can
> reproduce the bug with upstream llc.
>
>
> 3. Submit the bug [6]
>
> Once you have a small IR that can reproduce the problem with upstream
> llc, you can create a bug, attach the IR and provide the exact command
> line for llc (or another tool) that reproduces your problem. I imagine
> that, whatever the problem is, will be one of three things:
>
> 1. Your front-end is producing invalid IR
> 2. Your front-end is producing valid IR, but one not produced by
> Clang, so not heavily tested
> 3. You just found a bug in LLVM
>
> If we got 1 or 2, it's not something terribly wrong, or validate()
> wouldn't pass, but different enough to cause failures. In those cases,
> some middle-end optimisation is meddling it up and the back-end gets
> confused, but not completely so. This is possible, but less probably
> than number 3.
>
> I bet it's 3, maybe 2, unlikely 1.
>
> Let me know how it goes.
>
> cheers,
> --renato
>
> [1] http://llvm.org/docs/LangRef.html
> [2] https://embed.cs.utah.edu/creduce/
> [3] http://llvm.org/docs/Bugpoint.html
> [4] http://logan.tw/posts/2014/11/26/llvm-bugpoint/
> [5] https://zneak.github.io/fcd/2016/03/16/bugpoint.html
> [6] http://llvm.org/docs/HowToSubmitABug.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160707/e2a9c6f9/attachment.html>