<div dir="ltr"><p>Dear Renato Golin,</p><p>I am sorry for late reply because of the long vacation. </p><p>Recently, I have got a strange phenomenon about this issue between real target device and our own linux/arm emulator. </p><p><br></p><p>We cannot execute some unit tests on real target device (e.g., raspberry Pi2 board , ARM Chromebook )<br></p><p>However, we can always execute some unit tests tests on linux/arm emulator.</p><p>* linux/arm emulator - <a href="https://github.com/dotnet/coreclr/issues/3805">https://github.com/dotnet/coreclr/issues/3805</a></p><p><br></p><p>If you already have a similar experience like below case, Could you share me that? </p><p><br></p><p>For example, <br></p><p>1. on linux/arm emulator</p><p>arm@emul#> ./corerun  /nfs/common/CompEx/CompEx.exe </p><p>Beginning test case CompareExchange(Int64&,Int64,Int64) at 16. 7. 7. 오전 5:52:51</p><p>Random seed: 20010415; set environment variable CORECLR_SEED to this value to repro</p><p>Beginning scenario: CompareExchange(0,1,0)<br></p><p>BEFORE: T(0) NI(0) NV(1) I(0)</p><p>AFTER: T(1) NI(0) NV(1) I(0)</p><p>BEFORE: T(1) NI(0) NV(2) I(1)</p><p>AFTER: T(2) NI(1) NV(2) I(1)</p><p>Ending test case at 16. 7. 7. 오전 5:52:52<br></p><p>PASS</p><p><br></p><p>2. on real target device</p><p>root@target:/unit-test/runtime-arm-u1404-release-mode-20160707.2# ./corerun  /unit-test/common/CompEx/CompEx.exe </p><p>Bus error</p><p><br></p><div>Below is kernel log messages in case of the real target device. <br></div><div><div>[91909.525677] Alignment trap: not handling instruction ed940b00 at [<b21db3d2>]</div><div>[91909.525747] Unhandled fault: alignment exception (0x011) at 0xb1f7e3e3</div><div>[91909.527989] pgd = ed1e4000</div><div>[91909.530218] [b1f7e3e3] *pgd=58d53835, *pte=76bd77df, *ppte=76bd7e7f</div><div>[91909.532890] Alignment trap: not handling instruction ed940b00 at [<b21db3d2>]</div><div>[91909.535146] Unhandled fault: alignment exception (0x011) at 0xb1f7e3f5</div><div>[91909.537402] pgd = ed1e4000</div><div>[91909.539628] [b1f7e3f5] *pgd=58d53835, *pte=76bd77df, *ppte=76bd7e7f</div></div><div><br></div><div><br></div><p><br></p><p>BRs,</p><p>Geunsik Lim. </p>
<div class="gmail_quote">On Jun 21, 2016 12:49 AM, "Renato Golin" <<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On 20 June 2016 at 15:47, Geunsik Lim <<a href="mailto:leemgs@gmail.com" target="_blank">leemgs@gmail.com</a>> wrote:<br>
> Actually, there are a lot of files from the DotNet Core run-time (e.g.<br>
> CoreCLR).<br>
> In this case, How do we reproduce related IRs with upstream 'llc' command?<br>
<br>
It depends. If the IR your front-end generate strictly follows the<br>
Language Reference [1], then it's very simple (see below). If not,<br>
than it can be very hard and we may not be able to help you at all. :/<br>
<br>
If it does...<br>
<br>
1. Reduce the C# code to the smallest code that reproduces the error.<br>
<br>
In C++, I normally generate a pre-processed file and use that to<br>
reduce (since the reducer has access to the entirety of the source). I<br>
assume there is something similar in C#<br>
<br>
To reduce the size of the pre-processed file, I use creduce [2], but I<br>
have no idea how to do it in C#. Before creduce I used to do that<br>
manually, and I could clean up large amounts of useless stuff by<br>
removing code and looking for "unused" warnings.<br>
<br>
<br>
2. Generate IR<br>
<br>
Once you have a small enough sample, make sure it reproduces the<br>
original case. I'm also assuming your front-end can easily generate IR<br>
that can be consumed by LLVM as if it was passed directly (ie. no<br>
additional settings that influence code-gen other than what's in the<br>
IR or can be set via llc). If the IR is still big, you may still try<br>
to reduce it using bugpoint [3,4,5]. I'm not very familiar with it<br>
(though I really should), but it's supposed to work similar to creduce<br>
(among other things). Give it a shot.<br>
<br>
Once you have the IR, make sure your version of llc (if you have one)<br>
can still reproduce the problem and record the options you have used<br>
(something similar to "-triple thumbv7a-linux-gnueabihf -mfpu=vfpv3").<br>
Once you can reliably repeat the problem with your llc, try it with<br>
upstream's llc (recent 3.9-trunk). Fiddle with the parameters if you<br>
do pass them differently on your own toolchain, until you can<br>
reproduce the bug with upstream llc.<br>
<br>
<br>
3. Submit the bug [6]<br>
<br>
Once you have a small IR that can reproduce the problem with upstream<br>
llc, you can create a bug, attach the IR and provide the exact command<br>
line for llc (or another tool) that reproduces your problem. I imagine<br>
that, whatever the problem is, will be one of three things:<br>
<br>
1. Your front-end is producing invalid IR<br>
2. Your front-end is producing valid IR, but one not produced by<br>
Clang, so not heavily tested<br>
3. You just found a bug in LLVM<br>
<br>
If we got 1 or 2, it's not something terribly wrong, or validate()<br>
wouldn't pass, but different enough to cause failures. In those cases,<br>
some middle-end optimisation is meddling it up and the back-end gets<br>
confused, but not completely so. This is possible, but less probably<br>
than number 3.<br>
<br>
I bet it's 3, maybe 2, unlikely 1.<br>
<br>
Let me know how it goes.<br>
<br>
cheers,<br>
--renato<br>
<br>
[1] <a href="http://llvm.org/docs/LangRef.html" rel="noreferrer" target="_blank">http://llvm.org/docs/LangRef.html</a><br>
[2] <a href="https://embed.cs.utah.edu/creduce/" rel="noreferrer" target="_blank">https://embed.cs.utah.edu/creduce/</a><br>
[3] <a href="http://llvm.org/docs/Bugpoint.html" rel="noreferrer" target="_blank">http://llvm.org/docs/Bugpoint.html</a><br>
[4] <a href="http://logan.tw/posts/2014/11/26/llvm-bugpoint/" rel="noreferrer" target="_blank">http://logan.tw/posts/2014/11/26/llvm-bugpoint/</a><br>
[5] <a href="https://zneak.github.io/fcd/2016/03/16/bugpoint.html" rel="noreferrer" target="_blank">https://zneak.github.io/fcd/2016/03/16/bugpoint.html</a><br>
[6] <a href="http://llvm.org/docs/HowToSubmitABug.html" rel="noreferrer" target="_blank">http://llvm.org/docs/HowToSubmitABug.html</a><br>
</blockquote></div>
</div>