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

[Geunsik Lim via llvm-commits]

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?


---------------------------------------------------------------

 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)

---------------------------------------------------------------



On Jul 10, 2016 3:47 AM, "Renato Golin" <renato.golin at linaro.org> wrote:

> On 9 July 2016 at 17:40, Tim Northover <t.p.northover at gmail.com> wrote:
> > The crashing instruction (ed940b00) was "vldr d0, [r4]" which does not
> > permit unaligned accesses even when they're generally allowed (I
> > believe).
>
> Ah, this explains it! :)
>
>
> > There's a flag in one of the system registers controlling whether
> > unaligned accesses are generally permitted. But it's not usually set
> > to ban them on Linux, and wouldn't affect vldr anyway, so I don't
> > think it applies here.
>
> Indeed.
>
>
> > That would only work if the alignment fault was in the basic code. As
> > you've realised, it's more likely to be in the dynamically JITed
> > output. This option wouldn't help anyway though: LLVM already believes
> > it's doing an aligned access or it wouldn't use that instruction.
>
> Which makes it a lot harder to find. :(
>
> Can you reduce a piece of IR that always fail, even if it's on your
> JIT, it should give us clues as to what's going on.
>
> cheers,
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160711/feb435e7/attachment.html>