Bug#820220: [Pkg-julia-devel] Bug#820220: Bug#820220: Bug#820220: Bug#820220: julia: FTBFS on armel/armhf

[Riku Voipio]

On Sat, Apr 09, 2016 at 12:02:44PM +0200, Graham Inggs wrote:
> On 9 April 2016 at 00:53, peter green  wrote:
> > It would be useful if someone can reproduce the issue and get a dissasembly
> > of the failure location.
> 
> I hope this is useful.  I'll leave my screen session on abel.d.o. open
> in case I need to fetch more information.
> 
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
> WARNING: unable to determine host cpu name.
> exports.jl
> essentials.jl
> docs/bootstrap.jl
> base.jl
> reflection.jl
> build_h.jl
> version_git.jl
 
> Program received signal SIGILL, Illegal instruction.
> 0x940c5060 in julia_call_891 ()
> (gdb) disassemble $pc
> Dump of assembler code for function julia_call_891:
>0x940c5054 <+0>: push{r4, r5, r6, lr}
>0x940c5058 <+4>: vpush   {d8}
>0x940c505c <+8>: mov r0, #40 ; 0x28
> => 0x940c5060 <+12>:vorrd8, d0, d0

And yes, vorr is an NEON instruction.

>0x940c5064 <+16>:mov r4, r3
>0x940c5068 <+20>:mov r5, r2
>0x940c506c <+24>:mov r6, r1
>0x940c5070 <+28>:bl  0x940c50c4
>0x940c5074 <+32>:movwr1, #16432  ; 0x4030
>0x940c5078 <+36>:movtr1, #37900  ; 0x940c
>0x940c507c <+40>:ldr r1, [r1]
>0x940c5080 <+44>:stmda   r0, {r1, r6}
>0x940c5084 <+48>:ldr r1, [sp, #24]
>0x940c5088 <+52>:str r5, [r0, #4]
>0x940c508c <+56>:str r4, [r0, #8]
>0x940c5090 <+60>:str r1, [r0, #12]
>0x940c5094 <+64>:ldr r1, [sp, #28]
>0x940c5098 <+68>:str r1, [r0, #16]
>0x940c509c <+72>:ldrbr1, [sp, #32]
>0x940c50a0 <+76>:and r1, r1, #1
>0x940c50a4 <+80>:strbr1, [r0, #20]
>0x940c50a8 <+84>:ldr r1, [sp, #36]   ; 0x24
>0x940c50ac <+88>:str r1, [r0, #24]
>0x940c50b0 <+92>:vstrd8, [r0, #32]
>0x940c50b4 <+96>:vpop{d8}
>0x940c50b8 <+100>:   pop {r4, r5, r6, pc}
> End of assembler dump.

 

Bug#820220: [Pkg-julia-devel] Bug#820220: Bug#820220: Bug#820220: Bug#820220: julia: FTBFS on armel/armhf

[Graham Inggs]

On 9 April 2016 at 00:53, peter green  wrote:
> It would be useful if someone can reproduce the issue and get a dissasembly
> of the failure location.

I hope this is useful.  I'll leave my screen session on abel.d.o. open
in case I need to fetch more information.

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
WARNING: unable to determine host cpu name.
exports.jl
essentials.jl
docs/bootstrap.jl
base.jl
reflection.jl
build_h.jl
version_git.jl

Program received signal SIGILL, Illegal instruction.
0x940c5060 in julia_call_891 ()
(gdb) disassemble $pc
Dump of assembler code for function julia_call_891:
   0x940c5054 <+0>: push{r4, r5, r6, lr}
   0x940c5058 <+4>: vpush   {d8}
   0x940c505c <+8>: mov r0, #40 ; 0x28
=> 0x940c5060 <+12>:vorrd8, d0, d0
   0x940c5064 <+16>:mov r4, r3
   0x940c5068 <+20>:mov r5, r2
   0x940c506c <+24>:mov r6, r1
   0x940c5070 <+28>:bl  0x940c50c4
   0x940c5074 <+32>:movwr1, #16432  ; 0x4030
   0x940c5078 <+36>:movtr1, #37900  ; 0x940c
   0x940c507c <+40>:ldr r1, [r1]
   0x940c5080 <+44>:stmda   r0, {r1, r6}
   0x940c5084 <+48>:ldr r1, [sp, #24]
   0x940c5088 <+52>:str r5, [r0, #4]
   0x940c508c <+56>:str r4, [r0, #8]
   0x940c5090 <+60>:str r1, [r0, #12]
   0x940c5094 <+64>:ldr r1, [sp, #28]
   0x940c5098 <+68>:str r1, [r0, #16]
   0x940c509c <+72>:ldrbr1, [sp, #32]
   0x940c50a0 <+76>:and r1, r1, #1
   0x940c50a4 <+80>:strbr1, [r0, #20]
   0x940c50a8 <+84>:ldr r1, [sp, #36]   ; 0x24
   0x940c50ac <+88>:str r1, [r0, #24]
   0x940c50b0 <+92>:vstrd8, [r0, #32]
   0x940c50b4 <+96>:vpop{d8}
   0x940c50b8 <+100>:   pop {r4, r5, r6, pc}
End of assembler dump.

Bug#820220: [Pkg-julia-devel] Bug#820220: Bug#820220: Bug#820220: Bug#820220: julia: FTBFS on armel/armhf

[peter green]

On 08/04/16 20:55, Graham Inggs wrote:


Secondly, it should be possible to reproduce the fault by building in
an armhf schroot on abel.d.o, which has the same hardware as the
buildds.  A temporary solution would be to upload armhf binaries built
on asachi.d.o.
   
It would be useful if someone can reproduce the issue and get a 
dissasembly of the failure location.


My gut feeling is that llvm is trying to use neon without first checking 
it is supported. Afaict the marvell boards we are using for armhf 
buildds (and for the abel.d.o porterbox) don't have neon.



[1] 
https://buildd.debian.org/status/package.php?p=llvm-toolchain-3.8=unstable

   

Bug#820220: [Pkg-julia-devel] Bug#820220: Bug#820220: Bug#820220: Bug#820220: julia: FTBFS on armel/armhf

[Graham Inggs]

On 8 April 2016 at 21:16, Emilio Pozuelo Monfort  wrote:
> Why did you switch to 3.8? The default in unstable is 3.6 and in experimental 
> is
> 3.7.

I understood there were severe performance regressions with Julia on
LLVM > 3.3 that were only fixed in 3.8.

> I'm Cc'ing the arm and llvm lists, maybe they can give some hints.

Thanks.

I did ask on #debian-arm earlier today and was given some pointers by
suihkulokki.

Firstly, llvm-toolchain-3.8 hasn't actually built on armel yet [1], so
the julia build on armel is being attempted with llvm
1:3.8~svn247576-1 from llvm-toolchain-snapshot.

Secondly, it should be possible to reproduce the fault by building in
an armhf schroot on abel.d.o, which has the same hardware as the
buildds.  A temporary solution would be to upload armhf binaries built
on asachi.d.o.


[1] 
https://buildd.debian.org/status/package.php?p=llvm-toolchain-3.8=unstable