<div dir="ltr"><pre style="word-wrap:break-word">I have checked if we can resolve these issues with below patch. From my experience, 
I could successfully execute the existing 3804 unit tests of CoreCLR without any "Bus Error"
on raspberry pi2 board. However, I am not sure that this patch is appropriate solution to fix 
this issue because I have used memcpy() call. 
And, why we can not resolve this issue with just -mno-unaligned-access" compiler flag + -O3 using clang/llvm? <br></pre><pre style="color:rgb(0,0,0);word-wrap:break-word;white-space:pre-wrap"><span style="font-family:arial,sans-serif;color:rgb(34,34,34)">
---------------------------------------------------------------</span><br></pre><pre style="word-wrap:break-word"> src/jit/compiler.hpp | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/src/jit/compiler.hpp b/src/jit/compiler.hpp
index 9b10fd8..a04ff3f 100644
--- a/src/jit/compiler.hpp
+++ b/src/jit/compiler.hpp
@@ -759,11 +759,19 @@ inline
 
 inline
   signed __int32    getI4LittleEndian(const BYTE * ptr)
-{ return *(UNALIGNED signed __int32*)ptr; }
+{ 
+    signed __int32 buffer;
+    memcpy(&buffer, ptr, 4); // 4 bytes
+    return buffer;
+}
 
 inline
   signed __int64    getI8LittleEndian(const BYTE * ptr)
-{ return *(UNALIGNED signed __int64*)ptr; }
+{
+    signed __int64 buffer;
+    memcpy(&buffer, ptr, 8); // 8 bytes
+    return buffer;
+}
 
 inline
 float               getR4LittleEndian(const BYTE * ptr)</pre><pre style="color:rgb(0,0,0);word-wrap:break-word;white-space:pre-wrap"><pre style="word-wrap:break-word;white-space:pre-wrap">---------------------------------------------------------------</pre></pre><pre style="color:rgb(0,0,0);word-wrap:break-word;white-space:pre-wrap"><br></pre><pre style="color:rgb(0,0,0);word-wrap:break-word;white-space:pre-wrap"><br></pre>
<div class="gmail_quote">On Jul 10, 2016 3:47 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-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On 9 July 2016 at 17:40, Tim Northover <<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>> wrote:<br>
> The crashing instruction (ed940b00) was "vldr d0, [r4]" which does not<br>
> permit unaligned accesses even when they're generally allowed (I<br>
> believe).<br>
<br>
Ah, this explains it! :)<br>
<br>
<br>
> There's a flag in one of the system registers controlling whether<br>
> unaligned accesses are generally permitted. But it's not usually set<br>
> to ban them on Linux, and wouldn't affect vldr anyway, so I don't<br>
> think it applies here.<br>
<br>
Indeed.<br>
<br>
<br>
> That would only work if the alignment fault was in the basic code. As<br>
> you've realised, it's more likely to be in the dynamically JITed<br>
> output. This option wouldn't help anyway though: LLVM already believes<br>
> it's doing an aligned access or it wouldn't use that instruction.<br>
<br>
Which makes it a lot harder to find. :(<br>
<br>
Can you reduce a piece of IR that always fail, even if it's on your<br>
JIT, it should give us clues as to what's going on.<br>
<br>
cheers,<br>
--renato<br>
</blockquote></div>
</div>