Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Getting 'illegal instruction' error on armv6 #283

Closed
Cydox opened this issue Jan 10, 2015 · 66 comments
Closed

Getting 'illegal instruction' error on armv6 #283

Cydox opened this issue Jan 10, 2015 · 66 comments
Labels
arm Issues and PRs related to the ARM platform.

Comments

@Cydox
Copy link

Cydox commented Jan 10, 2015

I built io.js with the change #282 on armv6.
When running io.js i get an 'Illegal instruction' error. g++ and gcc are on version 4.8.3.
There where no errors while building. I don´t know what other information i could give you.
Just ask me for the information you need and i´ll post it.

@bnoordhuis
Copy link
Member

There was an rpi thread on v8-users recently. I don't know if you were involved but it lists a few things you can try. If nothing else, can you post the output of backtrace and disassemble from gdb?

@Cydox
Copy link
Author

Cydox commented Jan 11, 2015

I saw another thread. I´m trying command line arguments from that one. But this will take some time since the Pi is slow(probably will take till tomorrow morning). When it works should I do a PR so it will print an error message if people don't use these options and add it to #282 ?

@bnoordhuis
Copy link
Member

Yes, that would be great.

@bnoordhuis
Copy link
Member

@Cydox How did it work?

@fivdi
Copy link

fivdi commented Jan 11, 2015

I remember having the 'illegal instruction' error on the Raspberry Pi after successfully compiling node v0.11.8 or v0.11.9 on the Pi itself. I think the issue may be related to the following code (from deps/v8/src/base/cpu.cc):

    // Unfortunately, it seems that certain ARMv6-based CPUs
    // report an incorrect architecture number of 7!
    //
    // See http://code.google.com/p/android/issues/detail?id=10812
    //
    // We try to correct this by looking at the 'elf_format'
    // field reported by the 'Processor' field, which is of the
    // form of "(v7l)" for an ARMv7-based CPU, and "(v6l)" for
    // an ARMv6-one. For example, the Raspberry Pi is one popular
    // ARMv6 device that reports architecture 7.
    if (architecture_ == 7) {
      char* processor = cpu_info.ExtractField("Processor");
      if (HasListItem(processor, "(v6l)")) {
        architecture_ = 6;
      }
      delete[] processor;
    }

This code looks at the Processor field in file /proc/cpuinfo to see if it can find "(v6l)"

Everything works correctly on older versions of Raspbian with the following /proc/cpuinfo as the Processor field contains "(v6l)":

Processor   : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS    : 697.95
Features    : swp half thumb fastmult vfp edsp java tls 
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part    : 0xb76
CPU revision    : 7

Hardware    : BCM2708
Revision    : 0002
Serial      : 000000008a51a472

However, on newer versions of Raspbian "(v6l)" has been moved to the model name field, V8 doesn't find it, and assumes that the Pi has an ARMv7 processor:

processor   : 0
model name  : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS    : 2.00
Features    : swp half thumb fastmult vfp edsp java tls 
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part    : 0xb76
CPU revision    : 7

Hardware    : BCM2708
Revision    : 0002
Serial      : 000000008a51a472

Related issues:
nodejs/node-v0.x-archive#7222
https://code.google.com/p/v8/issues/detail?id=3112

@Cydox
Copy link
Author

Cydox commented Jan 12, 2015

This is really getting crazy now. An hour ago it the build on my Pi worked, but now i was giving it a second test but this time it gives me 'illegal instruction'. Runnig iojs --v8-options gives me

target arm v6 vfp3 hard ARMv7=1 VFP3=1 VFP32DREGS=1 NEON=0 SUDIV=0 UNALIGNED_ACCESSES=1 MOVW_MOVT_IMMEDIATE_LOADS=0 COHERENT_CACHE=0 USE_EABI_HARDFLOAT=1

so it is detecting armv7 again.
@bnoordhuis should we try to change the code in cpu.cc? Or is it a problem because it is in v8?

@Cydox
Copy link
Author

Cydox commented Jan 12, 2015

i think the reason why it didnt work is that
(as stated in https://code.google.com/p/v8/issues/detail?id=3112) the option arm-version=6
I was using is not in this version of v8 but in a newer one. And in
https://code.google.com/p/v8/issues/detail?id=3112 at the end there is a patch that
looks like it should work(obviously I dont have enough experience with a code working on
mutiple platforms). I´m gonna test the patch on my Pi and tell you wther it worked or not(and i´ll
try more then once now before saying it works).

@Cydox
Copy link
Author

Cydox commented Jan 12, 2015

I added this change to the Code:

if (architecture_ == 7) {
       std::cout << "7" << std::endl;
       char* processor;
       processor = cpu_info.ExtractField("Processor");
       if (HasListItem(processor, "(v6l)")) {
         architecture_ = 6;
       }
       processor = cpu_info.ExtractField("model name");
      if (HasListItem(processor, "(v6l)")) {
        std::cout << "6" << std::endl;
        architecture_ = 6;
      }
      delete[] processor;
    }
  }

I included iostream obviously and added the 'print' statements to see wether thoughs if statements
got called('not the best debugging probably'). Both if statements were called. ´So the architectue_
should have been set to 6 just like it needs to. But the output is just:

# ./iojs
7
6
Illegal instruction

I only did a short make so i didn´t need to compile the whole thing again. Could this have an
impact? I can´t think of anything else. iojs --v8-options returned that it is armv7 again.

@Cydox
Copy link
Author

Cydox commented Jan 12, 2015

gdb backtrace and disassemble:

gdb ./iojs
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/pi/io.js/iojs...done.
(gdb) run
Starting program: /home/pi/io.js/iojs
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".

Program received signal SIGILL, Illegal instruction.
0x00378a60 in _armv7_neon_probe ()
(gdb) backtrace
#0  0x00378a60 in _armv7_neon_probe ()
#1  0x00232cc0 in OPENSSL_cpuid_setup ()
#2  0x008a71d4 in __libc_csu_init ()
#3  0xb6cc5228 in __libc_start_main () from /lib/arm-linux-gnueabihf/libc.so.6
#4  0x00233068 in _start ()
(gdb) dissasemble
Undefined command: "dissasemble".  Try "help".
(gdb) disassemble
Dump of assembler code for function _armv7_neon_probe:
=> 0x00378a60 <+0>:     vorr    q15, q15, q15
   0x00378a64 <+4>:     bx      lr
End of assembler dump.

@indutny
Copy link
Member

indutny commented Jan 12, 2015

@Cydox please type c and hit Enter key after seeing this openssl thing. It is the way the OpenSSL detects platform. It sets SIGILL handler and executes the assembly code.

Again, this could be ignored, please hit the c after it.

@Cydox
Copy link
Author

Cydox commented Jan 12, 2015

like that?

(gdb) run
Starting program: /home/pi/io.js/iojs
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".

Program received signal SIGILL, Illegal instruction.
0x00378a60 in _armv7_neon_probe ()
(gdb) backtrace
#0  0x00378a60 in _armv7_neon_probe ()
#1  0x00232cc0 in OPENSSL_cpuid_setup ()
#2  0x008a71d4 in __libc_csu_init ()
#3  0xb6cc5228 in __libc_start_main () from /lib/arm-linux-gnueabihf/libc.so.6
#4  0x00233068 in _start ()
(gdb) c
Continuing.

Program received signal SIGILL, Illegal instruction.
0x00378a68 in _armv7_tick ()

@indutny
Copy link
Member

indutny commented Jan 12, 2015

What if you'll hit c again? ;)

@Cydox
Copy link
Author

Cydox commented Jan 12, 2015

here are a bunch of ´em :D

 c
Continuing.

Program received signal SIGILL, Illegal instruction.
0x00378a68 in _armv7_tick ()
(gdb) c
Continuing.
[New Thread 0xb6cab450 (LWP 26581)]
[New Thread 0xb64ab450 (LWP 26582)]
[New Thread 0xb5cab450 (LWP 26583)]
[New Thread 0xb54ab450 (LWP 26584)]
7
6

Program received signal SIGILL, Illegal instruction.
0x539242c0 in ?? ()
(gdb) c
Continuing.
[Thread 0xb54ab450 (LWP 26584) exited]
[Thread 0xb5cab450 (LWP 26583) exited]
[Thread 0xb64ab450 (LWP 26582) exited]
[Thread 0xb6cab450 (LWP 26581) exited]

Program terminated with signal SIGILL, Illegal instruction.
The program no longer exists.

@Cydox
Copy link
Author

Cydox commented Jan 14, 2015

Any new ideas on what fails here?

@bnoordhuis
Copy link
Member

It's most likely the last SIGILL that we're interested in. If all else fails, turn on coredumps with ulimit -c and disassemble it in gdb afterwards: gdb /path/to/iojs /path/to/corefile, then disassemble. Maybe inspect info threads as well (help threads for more info, or ask if you have questions.)

@silverwind
Copy link
Contributor

Is this any help?

GNU gdb (GDB) 7.8.2
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "armv6l-unknown-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from iojs...done.
(gdb) core core.iojs.1000.8e19a9713eb944d08076e926610092a7.20772.1421518688000000
[New LWP 20772]
[New LWP 20773]
[New LWP 20776]
[New LWP 20775]
[New LWP 20774]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `iojs'.
Program terminated with signal SIGILL, Illegal instruction.
#0  0x5b7242c0 in ?? ()
(gdb) disassemble
No function contains program counter for selected frame.
(gdb) info threads
  Id   Target Id         Frame
  5    Thread 0xb63df450 (LWP 20774) 0xb6d2c0e4 in pthread_cond_wait@@GLIBC_2.4 () from /usr/lib/libpthread.so.0
  4    Thread 0xb5bdf450 (LWP 20775) 0xb6d2c0e4 in pthread_cond_wait@@GLIBC_2.4 () from /usr/lib/libpthread.so.0
  3    Thread 0xb53df450 (LWP 20776) 0xb6d2c0e4 in pthread_cond_wait@@GLIBC_2.4 () from /usr/lib/libpthread.so.0
  2    Thread 0xb6bdf450 (LWP 20773) 0xb6d2c0e4 in pthread_cond_wait@@GLIBC_2.4 () from /usr/lib/libpthread.so.0
* 1    Thread 0xb6f3d000 (LWP 20772) 0x5b7242c0 in ?? ()
(gdb)

@silverwind
Copy link
Contributor

And here's thread 2:

(gdb) thread 2
[Switching to thread 2 (Thread 0xb6bdf450 (LWP 20773))]
#0  0xb6d2c0e4 in pthread_cond_wait@@GLIBC_2.4 () from /usr/lib/libpthread.so.0
(gdb) disassemble
Dump of assembler code for function pthread_cond_wait@@GLIBC_2.4:
   0xb6d2bfb8 <+0>: push    {r4, r5, r6, r7, r8, r9, r10, r11, lr}
   0xb6d2bfbc <+4>: sub sp, sp, #68 ; 0x44
   0xb6d2bfc0 <+8>: ldr r3, [r0, #32]
   0xb6d2bfc4 <+12>:    mov r4, r0
   0xb6d2bfc8 <+16>:    cmn r3, #1
   0xb6d2bfcc <+20>:    str r1, [sp, #12]
   0xb6d2bfd0 <+24>:    beq 0xb6d2c1fc <pthread_cond_wait@@GLIBC_2.4+580>
   0xb6d2bfd4 <+28>:    mov r3, #1
   0xb6d2bfd8 <+32>:    mov r6, #0
   0xb6d2bfdc <+36>:    str r6, [sp, #48]   ; 0x30
   0xb6d2bfe0 <+40>:    ldrex   r2, [r4]
   0xb6d2bfe4 <+44>:    cmp r2, r6
   0xb6d2bfe8 <+48>:    bne 0xb6d2bffc <pthread_cond_wait@@GLIBC_2.4+68>
   0xb6d2bfec <+52>:    strex   r1, r3, [r4]
   0xb6d2bff0 <+56>:    cmp r1, #0
   0xb6d2bff4 <+60>:    bne 0xb6d2bfe0 <pthread_cond_wait@@GLIBC_2.4+40>
   0xb6d2bff8 <+64>:    mcr 15, 0, r0, cr7, cr10, {5}
   0xb6d2bffc <+68>:    movne   r3, r6
   0xb6d2c000 <+72>:    bne 0xb6d2c1c8 <pthread_cond_wait@@GLIBC_2.4+528>
   0xb6d2c004 <+76>:    ldr r0, [sp, #12]
   0xb6d2c008 <+80>:    mov r1, #0
   0xb6d2c00c <+84>:    bl  0xb6d2a104 <__pthread_mutex_unlock_usercnt>
   0xb6d2c010 <+88>:    subs    r12, r0, #0
   0xb6d2c014 <+92>:    bne 0xb6d2c238 <pthread_cond_wait@@GLIBC_2.4+640>
   0xb6d2c018 <+96>:    ldrd    r2, [r4, #8]
   0xb6d2c01c <+100>:   ldr r12, [r4, #32]
   0xb6d2c020 <+104>:   ldr r1, [r4, #36]   ; 0x24
   0xb6d2c024 <+108>:   adds    r8, r2, #1
   0xb6d2c028 <+112>:   adc r9, r3, #0
   0xb6d2c02c <+116>:   cmn r12, #1
   0xb6d2c030 <+120>:   add r3, r1, #2
---Type <return> to continue, or q <return> to quit---
   0xb6d2c034 <+124>:   ldr r0, [r4, #4]
   0xb6d2c038 <+128>:   str r3, [r4, #36]   ; 0x24
   0xb6d2c03c <+132>:   ldrne   r3, [sp, #12]
   0xb6d2c040 <+136>:   add r0, r0, #1
   0xb6d2c044 <+140>:   strne   r3, [r4, #32]
   0xb6d2c048 <+144>:   ldr r1, [pc, #604]  ; 0xb6d2c2ac <pthread_cond_wait@@GLIBC_2.4+756>
   0xb6d2c04c <+148>:   add r3, sp, #32
   0xb6d2c050 <+152>:   str r0, [r4, #4]
   0xb6d2c054 <+156>:   str r3, [sp, #20]
   0xb6d2c058 <+160>:   mov r0, r3
   0xb6d2c05c <+164>:   ldr r3, [sp, #12]
   0xb6d2c060 <+168>:   strd    r8, [r4, #8]
   0xb6d2c064 <+172>:   add r2, sp, #48 ; 0x30
   0xb6d2c068 <+176>:   add r1, pc, r1
   0xb6d2c06c <+180>:   str r3, [sp, #56]   ; 0x38
   0xb6d2c070 <+184>:   str r4, [sp, #52]   ; 0x34
   0xb6d2c074 <+188>:   bl  0xb6d2e9ac <_pthread_cleanup_push>
   0xb6d2c078 <+192>:   ldrd    r2, [r4, #16]
   0xb6d2c07c <+196>:   eor r10, r6, #128   ; 0x80
   0xb6d2c080 <+200>:   add r9, r4, #4
   0xb6d2c084 <+204>:   strd    r2, [sp]
   0xb6d2c088 <+208>:   mov r5, #0
   0xb6d2c08c <+212>:   add r2, sp, #28
   0xb6d2c090 <+216>:   ldr r3, [r4, #40]   ; 0x28
   0xb6d2c094 <+220>:   mov r8, #1
   0xb6d2c098 <+224>:   str r2, [sp, #8]
   0xb6d2c09c <+228>:   eor r2, r6, #129    ; 0x81
   0xb6d2c0a0 <+232>:   str r2, [sp, #16]
   0xb6d2c0a4 <+236>:   str r3, [sp, #60]   ; 0x3c
   0xb6d2c0a8 <+240>:   ldr r11, [r4, #4]
   0xb6d2c0ac <+244>:   mcr 15, 0, r0, cr7, cr10, {5}
   0xb6d2c0b0 <+248>:   ldrex   r3, [r4]
---Type <return> to continue, or q <return> to quit---
   0xb6d2c0b4 <+252>:   strex   r2, r5, [r4]
   0xb6d2c0b8 <+256>:   cmp r2, #0
   0xb6d2c0bc <+260>:   bne 0xb6d2c0b0 <pthread_cond_wait@@GLIBC_2.4+248>
   0xb6d2c0c0 <+264>:   cmp r3, #1
   0xb6d2c0c4 <+268>:   bgt 0xb6d2c1e0 <pthread_cond_wait@@GLIBC_2.4+552>
   0xb6d2c0c8 <+272>:   bl  0xb6d2edcc <__pthread_enable_asynccancel>
   0xb6d2c0cc <+276>:   mov r7, #240    ; 0xf0
   0xb6d2c0d0 <+280>:   mov r2, r11
   0xb6d2c0d4 <+284>:   mov r1, r10
   0xb6d2c0d8 <+288>:   mov r3, #0
   0xb6d2c0dc <+292>:   str r0, [sp, #48]   ; 0x30
   0xb6d2c0e0 <+296>:   mov r0, r9
=> 0xb6d2c0e4 <+300>:   svc 0x00000000
   0xb6d2c0e8 <+304>:   ldr r0, [sp, #48]   ; 0x30
   0xb6d2c0ec <+308>:   bl  0xb6d2ee8c <__pthread_disable_asynccancel>
   0xb6d2c0f0 <+312>:   str r5, [sp, #28]
   0xb6d2c0f4 <+316>:   ldrex   r3, [r4]
   0xb6d2c0f8 <+320>:   cmp r3, #0
   0xb6d2c0fc <+324>:   bne 0xb6d2c110 <pthread_cond_wait@@GLIBC_2.4+344>
   0xb6d2c100 <+328>:   strex   r2, r8, [r4]
   0xb6d2c104 <+332>:   cmp r2, #0
   0xb6d2c108 <+336>:   bne 0xb6d2c0f4 <pthread_cond_wait@@GLIBC_2.4+316>
   0xb6d2c10c <+340>:   mcr 15, 0, r0, cr7, cr10, {5}
   0xb6d2c110 <+344>:   mov r0, r4
   0xb6d2c114 <+348>:   mov r1, r6
   0xb6d2c118 <+352>:   beq 0xb6d2c128 <pthread_cond_wait@@GLIBC_2.4+368>
   0xb6d2c11c <+356>:   ldr r2, [sp, #8]
   0xb6d2c120 <+360>:   str r3, [r2]
   0xb6d2c124 <+364>:   bl  0xb6d2ef88 <__lll_lock_wait>
   0xb6d2c128 <+368>:   ldr r2, [sp, #60]   ; 0x3c
   0xb6d2c12c <+372>:   ldr r3, [r4, #40]   ; 0x28
   0xb6d2c130 <+376>:   cmp r2, r3
---Type <return> to continue, or q <return> to quit---
   0xb6d2c134 <+380>:   bne 0xb6d2c168 <pthread_cond_wait@@GLIBC_2.4+432>
   0xb6d2c138 <+384>:   ldrd    r2, [r4, #16]
   0xb6d2c13c <+388>:   ldrd    r0, [sp]
   0xb6d2c140 <+392>:   cmp r3, r1
   0xb6d2c144 <+396>:   cmpeq   r2, r0
   0xb6d2c148 <+400>:   beq 0xb6d2c0a8 <pthread_cond_wait@@GLIBC_2.4+240>
   0xb6d2c14c <+404>:   ldrd    r0, [r4, #24]
   0xb6d2c150 <+408>:   cmp r1, r3
   0xb6d2c154 <+412>:   cmpeq   r0, r2
   0xb6d2c158 <+416>:   beq 0xb6d2c0a8 <pthread_cond_wait@@GLIBC_2.4+240>
   0xb6d2c15c <+420>:   adds    r0, r0, #1
   0xb6d2c160 <+424>:   adc r1, r1, #0
   0xb6d2c164 <+428>:   strd    r0, [r4, #24]
   0xb6d2c168 <+432>:   ldr r3, [r4, #36]   ; 0x24
   0xb6d2c16c <+436>:   ldr r1, [r4, #8]
   0xb6d2c170 <+440>:   ldr r2, [r4, #12]
   0xb6d2c174 <+444>:   sub r3, r3, #2
   0xb6d2c178 <+448>:   and r2, r2, r1
   0xb6d2c17c <+452>:   cmp r3, #1
   0xb6d2c180 <+456>:   cmnls   r2, #1
   0xb6d2c184 <+460>:   str r3, [r4, #36]   ; 0x24
   0xb6d2c188 <+464>:   beq 0xb6d2c290 <pthread_cond_wait@@GLIBC_2.4+728>
   0xb6d2c18c <+468>:   mov r3, #0
   0xb6d2c190 <+472>:   mcr 15, 0, r0, cr7, cr10, {5}
   0xb6d2c194 <+476>:   ldrex   r2, [r4]
   0xb6d2c198 <+480>:   strex   r1, r3, [r4]
   0xb6d2c19c <+484>:   cmp r1, #0
   0xb6d2c1a0 <+488>:   bne 0xb6d2c194 <pthread_cond_wait@@GLIBC_2.4+476>
   0xb6d2c1a4 <+492>:   cmp r2, #1
   0xb6d2c1a8 <+496>:   bgt 0xb6d2c278 <pthread_cond_wait@@GLIBC_2.4+704>
   0xb6d2c1ac <+500>:   ldr r0, [sp, #20]
   0xb6d2c1b0 <+504>:   mov r1, #0
---Type <return> to continue, or q <return> to quit---
   0xb6d2c1b4 <+508>:   bl  0xb6d2e9d0 <_pthread_cleanup_pop>
   0xb6d2c1b8 <+512>:   ldr r0, [sp, #12]
   0xb6d2c1bc <+516>:   bl  0xb6d2a990 <__pthread_mutex_cond_lock>
   0xb6d2c1c0 <+520>:   add sp, sp, #68 ; 0x44
   0xb6d2c1c4 <+524>:   pop {r4, r5, r6, r7, r8, r9, r10, r11, pc}
   0xb6d2c1c8 <+528>:   mov r6, r3
   0xb6d2c1cc <+532>:   str r2, [sp, #48]   ; 0x30
   0xb6d2c1d0 <+536>:   mov r0, r4
   0xb6d2c1d4 <+540>:   mov r1, r6
   0xb6d2c1d8 <+544>:   bl  0xb6d2ef88 <__lll_lock_wait>
   0xb6d2c1dc <+548>:   b   0xb6d2c004 <pthread_cond_wait@@GLIBC_2.4+76>
   0xb6d2c1e0 <+552>:   mov r0, r4
   0xb6d2c1e4 <+556>:   ldr r1, [sp, #16]
   0xb6d2c1e8 <+560>:   mov r2, #1
   0xb6d2c1ec <+564>:   mov r3, #0
   0xb6d2c1f0 <+568>:   mov r7, #240    ; 0xf0
   0xb6d2c1f4 <+572>:   svc 0x00000000
   0xb6d2c1f8 <+576>:   b   0xb6d2c0c8 <pthread_cond_wait@@GLIBC_2.4+272>
   0xb6d2c1fc <+580>:   mov r3, #0
   0xb6d2c200 <+584>:   str r3, [sp, #48]   ; 0x30
   0xb6d2c204 <+588>:   mov r3, #1
   0xb6d2c208 <+592>:   ldrex   r2, [r4]
   0xb6d2c20c <+596>:   cmp r2, #0
   0xb6d2c210 <+600>:   bne 0xb6d2c224 <pthread_cond_wait@@GLIBC_2.4+620>
   0xb6d2c214 <+604>:   strex   r1, r3, [r4]
   0xb6d2c218 <+608>:   cmp r1, #0
   0xb6d2c21c <+612>:   bne 0xb6d2c208 <pthread_cond_wait@@GLIBC_2.4+592>
   0xb6d2c220 <+616>:   mcr 15, 0, r0, cr7, cr10, {5}
   0xb6d2c224 <+620>:   strne   r2, [sp, #48]   ; 0x30
   0xb6d2c228 <+624>:   movne   r6, #128    ; 0x80
   0xb6d2c22c <+628>:   bne 0xb6d2c1d0 <pthread_cond_wait@@GLIBC_2.4+536>
   0xb6d2c230 <+632>:   mov r6, #128    ; 0x80
---Type <return> to continue, or q <return> to quit---
   0xb6d2c234 <+636>:   b   0xb6d2c004 <pthread_cond_wait@@GLIBC_2.4+76>
   0xb6d2c238 <+640>:   mov r3, #0
   0xb6d2c23c <+644>:   mcr 15, 0, r0, cr7, cr10, {5}
   0xb6d2c240 <+648>:   ldrex   r2, [r4]
   0xb6d2c244 <+652>:   strex   r1, r3, [r4]
   0xb6d2c248 <+656>:   cmp r1, #0
   0xb6d2c24c <+660>:   bne 0xb6d2c240 <pthread_cond_wait@@GLIBC_2.4+648>
   0xb6d2c250 <+664>:   cmp r2, #1
   0xb6d2c254 <+668>:   movle   r0, r12
   0xb6d2c258 <+672>:   ble 0xb6d2c1c0 <pthread_cond_wait@@GLIBC_2.4+520>
   0xb6d2c25c <+676>:   mov r0, r4
   0xb6d2c260 <+680>:   eor r1, r6, #129    ; 0x81
   0xb6d2c264 <+684>:   mov r2, #1
   0xb6d2c268 <+688>:   mov r7, #240    ; 0xf0
   0xb6d2c26c <+692>:   svc 0x00000000
   0xb6d2c270 <+696>:   mov r0, r12
   0xb6d2c274 <+700>:   b   0xb6d2c1c0 <pthread_cond_wait@@GLIBC_2.4+520>
   0xb6d2c278 <+704>:   mov r0, r4
   0xb6d2c27c <+708>:   eor r1, r6, #129    ; 0x81
   0xb6d2c280 <+712>:   mov r2, #1
   0xb6d2c284 <+716>:   mov r7, #240    ; 0xf0
   0xb6d2c288 <+720>:   svc 0x00000000
   0xb6d2c28c <+724>:   b   0xb6d2c1ac <pthread_cond_wait@@GLIBC_2.4+500>
   0xb6d2c290 <+728>:   add r0, r4, #36 ; 0x24
   0xb6d2c294 <+732>:   eor r1, r6, #129    ; 0x81
   0xb6d2c298 <+736>:   mov r2, #1
   0xb6d2c29c <+740>:   mov r3, #0
   0xb6d2c2a0 <+744>:   mov r7, #240    ; 0xf0
   0xb6d2c2a4 <+748>:   svc 0x00000000
   0xb6d2c2a8 <+752>:   b   0xb6d2c18c <pthread_cond_wait@@GLIBC_2.4+468>
   0xb6d2c2ac <+756>:           ; <UNDEFINED> instruction: 0xfffffd7c
End of assembler dump.

Let me know if you need the dump and/or binary.

@bnoordhuis
Copy link
Member

@silverwind The second thread looks healthy, it's sleeping in a system call. What does disassemble $pc,+32 print for the first thread?

@silverwind
Copy link
Contributor

(gdb) disassemble $pc,+32
Dump of assembler code from 0x5b7242c0 to 0x5b7242e0:
=> 0x5b7242c0:  movw    r10, #63532 ; 0xf82c
   0x5b7242c4:  movt    r10, #473   ; 0x1d9
   0x5b7242c8:  push    {r1}        ; (str r1, [sp, #-4]!)
   0x5b7242cc:  push    {r2}        ; (str r2, [sp, #-4]!)
   0x5b7242d0:  add r2, r4, r3, lsl #2
   0x5b7242d4:  b   0x5b7242e4
   0x5b7242d8:  ldr r0, [r4], #4
   0x5b7242dc:  ldr r0, [r0]
End of assembler dump.

@bnoordhuis
Copy link
Member

Thanks. I think V8's feature detection is failing here. Does iojs --noenable_armv7 work?

@silverwind
Copy link
Contributor

Does iojs --noenable_armv7 work

Unfortunately not. It gives a very similar crash:

(gdb) disassemble $pc,+32
Dump of assembler code from 0x351242c0 to 0x351242e0:
=> 0x351242c0:  movw    r10, #26684 ; 0x683c
   0x351242c4:  movt    r10, #455   ; 0x1c7
   0x351242c8:  push    {r1}        ; (str r1, [sp, #-4]!)
   0x351242cc:  push    {r2}        ; (str r2, [sp, #-4]!)
   0x351242d0:  add r2, r4, r3, lsl #2
   0x351242d4:  b   0x351242e4
   0x351242d8:  ldr r0, [r4], #4
   0x351242dc:  ldr r0, [r0]
End of assembler dump.

Right now, I'm trying to compile with some flags, but it'll be another 1-2 hours before it completes:

make arm_version=6 armfpu=vfp armfloatabi=hard armv7=false

@bnoordhuis
Copy link
Member

If you still have the binary around, can you try iojs --noenable_movw_movt (possibly combined with --noenable_armv7)?

@silverwind
Copy link
Contributor

Still very much the same, with the first or both flags:

(gdb) core core.iojs.1000.b18201d96bbe48ea9ccce34bd4e17dc7.23537.1421526387000000
[New LWP 23537]
[New LWP 23538]
[New LWP 23541]
[New LWP 23540]
[New LWP 23539]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `iojs --noenable_movw_movt --noenable_armv7'.
Program terminated with signal SIGILL, Illegal instruction.
#0  0x208242c0 in ?? ()
(gdb) info threads
  Id   Target Id         Frame
  5    Thread 0xb6401450 (LWP 23539) 0xb6d4e0e4 in pthread_cond_wait@@GLIBC_2.4 () from /usr/lib/libpthread.so.0
  4    Thread 0xb5c01450 (LWP 23540) 0xb6d4e0e4 in pthread_cond_wait@@GLIBC_2.4 () from /usr/lib/libpthread.so.0
  3    Thread 0xb5401450 (LWP 23541) 0xb6d4e0e4 in pthread_cond_wait@@GLIBC_2.4 () from /usr/lib/libpthread.so.0
  2    Thread 0xb6c01450 (LWP 23538) 0xb6d4e0e4 in pthread_cond_wait@@GLIBC_2.4 () from /usr/lib/libpthread.so.0
* 1    Thread 0xb6f5f000 (LWP 23537) 0x208242c0 in ?? ()
(gdb) disassemble $pc,+32
Dump of assembler code from 0x208242c0 to 0x208242e0:
=> 0x208242c0:  movw    r10, #38996 ; 0x9854
   0x208242c4:  movt    r10, #550   ; 0x226
   0x208242c8:  push    {r1}        ; (str r1, [sp, #-4]!)
   0x208242cc:  push    {r2}        ; (str r2, [sp, #-4]!)
   0x208242d0:  add r2, r4, r3, lsl #2
   0x208242d4:  b   0x208242e4
   0x208242d8:  ldr r0, [r4], #4
   0x208242dc:  ldr r0, [r0]
End of assembler dump.

@bnoordhuis
Copy link
Member

Hrm, okay. Maybe it's worth building with ./configure --without-snapshot. Flags won't have effect when the movw/movt is baked into the snapshot.

@silverwind
Copy link
Contributor

It's already been build with ./configure --without-snapshot, as doing otherwise results in this:

make -C out BUILDTYPE=Release V=1
make[1]: Entering directory '/home/silverwind/git/io.js/out'
  LD_LIBRARY_PATH=/home/silverwind/git/io.js/out/Release/lib.host:/home/silverwind/git/io.js/out/Release/lib.target:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; cd ../deps/v8/tools/gyp; mkdir -p /home/silverwind/git/io.js/out/Release/obj.target/v8_snapshot/geni; "/home/silverwind/git/io.js/out/Release/mksnapshot" --log-snapshot-positions --logfile "/home/silverwind/git/io.js/out/Release/obj.target/v8_snapshot/geni/snapshot.log" "/home/silverwind/git/io.js/out/Release/obj.target/v8_snapshot/geni/snapshot.cc"
/bin/sh: line 1: 16261 Illegal instruction     (core dumped) "/home/silverwind/git/io.js/out/Release/mksnapshot" --log-snapshot-positions --logfile "/home/silverwind/git/io.js/out/Release/obj.target/v8_snapshot/geni/snapshot.log" "/home/silverwind/git/io.js/out/Release/obj.target/v8_snapshot/geni/snapshot.cc"
deps/v8/tools/gyp/v8_snapshot.target.mk:13: recipe for target '/home/silverwind/git/io.js/out/Release/obj.target/v8_snapshot/geni/snapshot.cc' failed
make[1]: *** [/home/silverwind/git/io.js/out/Release/obj.target/v8_snapshot/geni/snapshot.cc] Error 132
make[1]: Leaving directory '/home/silverwind/git/io.js/out'
Makefile:52: recipe for target 'iojs' failed
make: *** [iojs] Error 2

Let's await the current build, at least one guy on this thread reports success with these make options.

@Cydox
Copy link
Author

Cydox commented Jan 17, 2015

@silverwind I already tried those options youre building with right now. I didn´t have succes
with them.

@bnoordhuis I´m found out in some other thread that it could help to build with -march=armv6 -mfpu=vfp -mfloat-abi=hard as gcc and g++ compiler options. But I´m not home this week so I can only acces Github and my Pi through my phone. So I´m struggling on finding out how to use those options.
I already tried to do make CFLAGS='<the options>' CXXFLAGS='<the options>'. But i think it stopped using those options when it came to compile v8.

How can I use those options? It´s hard to figure out how the makefiles work on a screen of a phone.

@bnoordhuis
Copy link
Member

@Cydox It's probably easiest to hack them into the 'cflags' list in common.gypi, the one that now says ['-O3','-ffunction-sections', '-fdata-sections']. I'm not sure if that is going to be enough, though; you also need to stop V8 from generating incompatible machine code.

@Cydox
Copy link
Author

Cydox commented Jan 17, 2015

Isn´t the architecture detection done in cpu.cc?
If thats the case then I think that this might not be the problem because when I used the code:

if (architecture_ == 7) {
       std::cout << "7" << std::endl;
       char* processor;
       processor = cpu_info.ExtractField("Processor");
       if (HasListItem(processor, "(v6l)")) {
         architecture_ = 6;
       }
       processor = cpu_info.ExtractField("model name");
      if (HasListItem(processor, "(v6l)")) {
        std::cout << "6" << std::endl;
        architecture_ = 6;
      }
      delete[] processor;
    }
  }

It printed '6' so it should have detected armv6 right? Or am I horrible wrong with this point?

@bnoordhuis
Copy link
Member

@Cydox I'm not 100% sure but I believe some ARMv6 cores support the movw/movt instructions. V8 may think yours is one when it's not (assuming it's crashing for the same reason as @silverwind.)

@indutny
Copy link
Member

indutny commented Jan 22, 2015

Seems to be mostly timeouts...

@bnoordhuis
Copy link
Member

@silverwind Thanks! looks like io.js is holding up fairly well. Most failures seem to be in timing sensitive tests, the only real failures are parallel/test-dgram-error-message-address and maybe parallel/test-stringbytes-external and parallel/test-process-active-wraps.

@rvagg
Copy link
Member

rvagg commented Jan 22, 2015

Woohoo! Great work everyone!

@indutny
Copy link
Member

indutny commented Jan 22, 2015

thanks everyone!

bnoordhuis added a commit to bnoordhuis/io.js that referenced this issue Jan 22, 2015
The elf_platform suffix in /proc/cpuinfo moved to the model name field
in Linux 3.8.

Out-of-tree patch pending https://codereview.chromium.org/867713003/

Fixes: nodejs#283
PR-URL: nodejs#559
Reviewed-By: Fedor Indutny <fedor@indutny.com>
bnoordhuis added a commit to bnoordhuis/io.js that referenced this issue Jan 22, 2015
VFPv3 is ARMv7-only, enabling it for ARMv6 is therefore always wrong.
Mea culpa, I do believe I'm the original author of that change.

Fixes: nodejs#283
PR-URL: nodejs#559
Reviewed-By: Fedor Indutny <fedor@indutny.com>
@SynerG
Copy link

SynerG commented Jan 26, 2015

Awesome work, thank you!
Please, take into account that armv6 is still not compiled by the CI, so armv6 builds are not available for download.
It would be great if you consider to include the appropriate configuration in Jenkins.
Armv6 is probably one of the worst targets to be built locally as hardware such as Raspberry Pi is extremely slow and some distributions don't even have gcc/g++ > 4.8, so users would really appreciate a precompiled package. Thanks!

@rvagg
Copy link
Member

rvagg commented Jan 26, 2015

@SynerG yes this is on my list of things to do very soon, the real hassle is getting a good setup for doing builds with Raspbian Wheezy as lowest-common-denominator platform, of course gcc is the problem there.

@SynerG
Copy link

SynerG commented Jan 27, 2015

@rvagg thank you for working on the issue.
I have no previous experience setting up a cross-compilation environment for armv6, but maybe the tips here could be useful:
https://aabdelfattah.wordpress.com/2014/03/08/cross-compiling-a-pie-the-raspberry-pi-ultimate-guide/

In case it is of any help, I have just built io.js directly on my RPi using Xbian (based on Raspbian Wheezy).
The stock gcc was 4.6.x.
Using Wheezy repo, I was able to install gcc/g++ 4.8.2 (by doing: sudo apt-get install -y gcc-4.8 g++-4.8)
Using Jessie repo, the gcc/g++ version installed was 4.8.3.
Compilation on the Rpi took over 7 hours using gcc 4.8.3.
io.js --version states v1.0.5 and my app which uses some ES6 features seems to be working properly ;)

@rvagg
Copy link
Member

rvagg commented Jan 27, 2015

FYI, this is pretty good, only 12 failures on a pi, mostly timeouts I suspect: https://jenkins-iojs.nodesource.com/job/iojs+any-pr+multi/118/nodes=iojs-armv6-raspbian-wheezy/console

Also attempting a nightly: https://jenkins-iojs.nodesource.com/job/iojs+release+nightly/68/nodes=iojs-armv6-raspbian-wheezy/console

It's all very slow of course because it's native, but I'm hoping that ccache will make this more reasonable to include as a regular test target and build target. Time will tell.

@silverwind
Copy link
Contributor

@rvagg I think we can close this issue as solved. I looked through the current test failures and they all seem to be various timeouts, nothing serious.

@rvagg
Copy link
Member

rvagg commented Feb 3, 2015

@silverwind agreed; I did start work on a "very-slow" flag for the test builds so that when you're running the test suite on armv6, various tests can choose to extend their timeouts and time expectations, just so we can get past them. In one instance there, the max time expected is 1s but it's taking above 6s on a RPi. Process startup is particularly slow which is a big problem for the test suite.

@rvagg rvagg closed this as completed Feb 3, 2015
misterdjules pushed a commit to misterdjules/node that referenced this issue Mar 30, 2015
Port 297cadb from io.js.

Original commit message:

  The elf_platform suffix in /proc/cpuinfo moved to the model name field
  in Linux 3.8.

  Out-of-tree patch pending https://codereview.chromium.org/867713003/

  Fixes: nodejs/node#283
  PR-URL: nodejs/node#559
  Reviewed-By: Fedor Indutny <fedor@indutny.com>
misterdjules pushed a commit to misterdjules/node that referenced this issue Mar 30, 2015
Port 7d9d756 from io.js.

Original commit message:

  VFPv3 is ARMv7-only, enabling it for ARMv6 is therefore always wrong.
  Mea culpa, I do believe I'm the original author of that change.

  Fixes: nodejs/node#283
  PR-URL: nodejs/node#559
  Reviewed-By: Fedor Indutny <fedor@indutny.com>
@magic890
Copy link

magic890 commented Jul 3, 2015

Here is the official patch from V8 team: https://github.com/v8/v8-git-mirror/blob/master/src/base/cpu.cc#L483-L499

I have created a pull request to solve this issue: #25625

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
arm Issues and PRs related to the ARM platform.
Projects
None yet
Development

No branches or pull requests

10 participants