SIGILL on v0.12.4 on cortex-A5

[gizero]

Can't figure out whether this is related or not with previous issues on ARM detection, hence I'm submitting as a new report.

v0.12.4 builds with no issues but deterministically fails at runtime with SIGILL on a cortex-A5 (Atmel SAMA5D3 Xplained board). Downgrading to v0.10.38 works on the same platform.

Build details:

• the target system is Linux 3.18
• cross-compiling with gcc 4.9.1

Collected reports follow, mostly inspired by similar issues reported in the past. Please let me know how to collect more info or debug any further.

Generated build configuration:

creating  ./icu_config.gypi
{ 'target_defaults': { 'cflags': [],
                       'default_configuration': 'Release',
                       'defines': [],
                       'include_dirs': [],
                       'libraries': ['-lssl', '-lcrypto']},
  'variables': { 'arm_float_abi': 'hard',
                 'arm_fpu': 'vfpv3',
                 'arm_thumb': 0,
                 'arm_version': '7',
                 'clang': 0,
                 'gcc_version': 49,
                 'host_arch': 'arm',
                 'icu_small': 'false',
                 'node_install_npm': 'true',
                 'node_prefix': '/usr',
                 'node_shared_cares': 'false',
                 'node_shared_http_parser': 'false',
                 'node_shared_libuv': 'false',
                 'node_shared_openssl': 'true',
                 'node_shared_v8': 'false',
                 'node_shared_zlib': 'false',
                 'node_tag': '',
                 'node_use_dtrace': 'false',
                 'node_use_etw': 'false',
                 'node_use_mdb': 'false',
                 'node_use_openssl': 'true',
                 'node_use_perfctr': 'false',
                 'openssl_no_asm': 0,
                 'python': '/usr/bin/python',
                 'target_arch': 'arm',
                 'uv_library': 'static_library',
                 'uv_parent_path': '/deps/uv/',
                 'uv_use_dtrace': 'false',
                 'v8_enable_gdbjit': 0,
                 'v8_enable_i18n_support': 0,
                 'v8_no_strict_aliasing': 1,
                 'v8_optimized_debug': 0,
                 'v8_random_seed': 0,
                 'v8_use_snapshot': 'false',
                 'want_separate_host_toolset': 0}}

Here is what /proc/cpuinfo reports for the target architecture:

processor       : 0
model name      : ARMv7 Processor rev 1 (v7l)
Features        : half thumb fastmult vfp edsp vfpv3 vfpv3d16 tls vfpv4 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xc05
CPU revision    : 1

Hardware        : Atmel SAMA5
Revision        : 0000
Serial          : 0000000000000000

gdb shows the following context for the illegal instruction exception:

Program received signal SIGILL, Illegal instruction.
0x0054da10 in v8::base::Time::ToJsTime (this=this@entry=0xbefff948) at ../deps/v8/src/base/platform/time.cc:354

(gdb) bt
#0  0x0054da10 in v8::base::Time::ToJsTime (this=this@entry=0xbefff948) at ../deps/v8/src/base/platform/time.cc:354
#1  0x0054f354 in v8::base::OS::TimeCurrentMillis () at ../deps/v8/src/base/platform/platform-posix.cc:350
#2  0x0024d024 in v8::internal::GCTracer::GCTracer (this=0x707928, heap=<optimized out>) at ../deps/v8/src/heap/gc-tracer.cc:85
#3  0x0025fd44 in v8::internal::Heap::Heap (this=0x707098) at ../deps/v8/src/heap/heap.cc:139
#4  0x00325748 in v8::internal::Isolate::Isolate (this=0x707088) at ../deps/v8/src/isolate.cc:1477
#5  0x0014fd6c in v8::Isolate::New () at ../deps/v8/src/api.cc:6537
#6  0x004d90c0 in node::Init (argc=argc@entry=0xbefffb64, argv=argv@entry=0x707008, exec_argc=exec_argc@entry=0xbefffb68, 
    exec_argv=exec_argv@entry=0xbefffb6c) at ../src/node.cc:3453
#7  0x004d9c9c in node::Start (argc=1, argv=0x707008) at ../src/node.cc:3684
#8  0xb6b634c4 in __libc_start_main (main=0xbefffd84, argc=-1228443648, argv=0xb6b634c4 <__libc_start_main+276>, init=<optimized out>, 
    fini=0x550b68 <__libc_csu_fini>, rtld_fini=0xb6fe77c0 <_dl_fini>, stack_end=0xbefffd84) at libc-start.c:289
#9  0x00134fec in _start () at ../sysdeps/arm/start.S:124

(gdb) disassemble 
Dump of assembler code for function v8::base::Time::ToJsTime() const:
   0x0054d9e0 <+0>:     ldrd    r0, [r0]
   0x0054d9e4 <+4>:     orrs    r3, r0, r1
   0x0054d9e8 <+8>:     beq     0x54da1c <v8::base::Time::ToJsTime() const+60>
   0x0054d9ec <+12>:    mvn     r3, #-2147483648        ; 0x80000000
   0x0054d9f0 <+16>:    mvn     r2, #0
   0x0054d9f4 <+20>:    cmp     r1, r3
   0x0054d9f8 <+24>:    cmpeq   r0, r2
   0x0054d9fc <+28>:    beq     0x54da24 <v8::base::Time::ToJsTime() const+68>
   0x0054da00 <+32>:    push    {r11, lr}
   0x0054da04 <+36>:    add     r11, sp, #4
   0x0054da08 <+40>:    bl      0x1327ac <__aeabi_l2d>
   0x0054da0c <+44>:    vldr    d0, [pc, #28]   ; 0x54da30 <v8::base::Time::ToJsTime() const+80>
=> 0x0054da10 <+48>:    vmov    d16, r0, r1
   0x0054da14 <+52>:    vdiv.f64        d0, d16, d0
   0x0054da18 <+56>:    pop     {r11, pc}
   0x0054da1c <+60>:    vldr    d0, [pc, #20]   ; 0x54da38 <v8::base::Time::ToJsTime() const+88>
   0x0054da20 <+64>:    bx      lr
   0x0054da24 <+68>:    vldr    d0, [pc, #20]   ; 0x54da40 <v8::base::Time::ToJsTime() const+96>
   0x0054da28 <+72>:    bx      lr
   0x0054da2c <+76>:    nop     {0}
   0x0054da30 <+80>:    andeq   r0, r0, r0
   0x0054da34 <+84>:    addmi   r4, pc, r0
   0x0054da38 <+88>:    andeq   r0, r0, r0
   0x0054da3c <+92>:    andeq   r0, r0, r0
   0x0054da40 <+96>:                    ; <UNDEFINED> instruction: 0xffffffff
   0x0054da44 <+100>:   svcvc   0x00efffff
End of assembler dump.

[misterdjules]

It seems that all variants of vmov are supported on vfpv3, and it seems it's what configure detected.
Your ARM architecture seems to use vfpv4 though, are floating point ABIs backward compatible? That is, can code that is built for vfpv3 run on vfpv4. I would assume yes, but I don't know. If that is true, this SIGILL error is definitely surprising.

I'm not familiar with ARM, so /cc @wilson0x4d @sxa555 who have been helpful in investigating ARM issues in the past.

[gizero]

Maybe the problem here is with the register referenced by vmov. After further investigation looks like my target CPU (Atmel SAMA5D3) actually implements VFPv4-D16, an implementation of VFPv4 that provides only 16 double-precision registers. If this is true, it means d16 is not a valid double precision register to store the content of r0 and r1.

   0x0054da0c <+44>:    vldr    d0, [pc, #28]   ; 0x54da30 <v8::base::Time::ToJsTime() const+80>
=> 0x0054da10 <+48>:    vmov    d16, r0, r1
   0x0054da14 <+52>:    vdiv.f64        d0, d16, d0

This is what the datasheet states:

The Floating-Point Unit (FPU) supports the ARMv7 VFPv4-D16 architecture without Advanced SIMD extensions (NEON)

Linux kernel capabilities reporting by /proc/cpuinfo seems not to distinguish between vfpv4 and vfpv4d16 as it does for vfpv3 and vfpv3d16

It should be possible to make the compiler aware of it. Will try to rebuild with -mfpu=vfpv4-d16 and see what happens.

Still out of my understanding why this only pops out with v0.12.x... Inspection of disassembled code from v0.10.38 shows no instance of vmov targeting registers d16-d31.

[gizero]

After wrapping my head around this, I figured out it was already reported in #14086 by @Ferk. I'll give its patch a test and report back.