process.arch not matching with systems arch output for ARM

[Regaddi]

• Version: v6.9.1
• Platform: Linux jessie 3.4.0-g9e59eab deps: update openssl to 1.0.1j #1 SMP PREEMPT Tue Nov 1 00:35:37 UTC 2016 armv7l GNU/Linux
• Subsystem: Debian jessie, armv7l

When calling process.arch it returns 'arm', which is not the expected output. I'd expect process.arch to return the exact same value as uname or arch on my linux system returns.

However I found out, that process.config.variables.arm_version returns the correct ARM version.
But anyway: when handling with specific ARM versions, it would be helpful, if process.arch returned the correct architecture value, as arch does.

Console output:

$ node
> process.arch
'arm'
> process.config.variables.arm_version
'7'
> .exit
$ uname -m
armv7l
$ arch
armv7l

This problem occured for me first, when trying to build Atom with electron-packager for my ARMv7 Debian Jessie system.

Related issues:

electron/packager#523
atom/atom#5584

[mscdex]

process.arch exists to provide a normalized architecture value. If you want the information provided by uname, then there would probably need to be a new os module function that returns the machine value from the struct utsname on *nix.

One problem with that though is Windows. While it has a GetSystemInfo() that returns a structure containing processor architecture, they're not string values. Also the ARM value is generic, so there is no indicator whether it's ARMv7, ARMv8, etc. (unlike uname which does provide such information).

[Regaddi]

I think this is still necessary. When it comes to build tasks, there are slight differences between ARM versions and you need (in best case) an integrated way to check for specific ARM versions.

So this might be some sort of feature request.

[rvagg]

process.arch isn't going to change from 'arm', that would break existing uses too hard, process.config.variables.arm_version exists and is already being used in the ecosystem for this kind of thing.

$ node -p 'process.arch + "v" + process.config.variables.arm_version'
armv7

[XadillaX]

I think something goes wrong with arm_version.

This is under my Raspberry Pi 3:

$ uname -m
armv7l
$ node -p "process.config.variables.arm_version"
6

[XadillaX]

I think its because of this:

$ echo '\n' | gcc -dM -E - | grep __ARM_ARCH
#define __ARM_ARCH_ISA_ARM 1
#define __ARM_ARCH_6__ 1
#define __ARM_ARCH_ISA_THUMB 1
#define __ARM_ARCH 6

and refers to https://github.com/nodejs/node/blob/master/configure#L650-L685

[silverwind]

Looking fine on my RPi3 (using Arch Linux ARM):

$ uname -m
armv7l
$ node -p "process.config.variables.arm_version"
7
$ echo '\n' | gcc -dM -E - | grep __ARM_ARCH
27:#define __ARM_ARCH_ISA_ARM 1
245:#define __ARM_ARCH_PROFILE 65
292:#define __ARM_ARCH_ISA_THUMB 2
294:#define __ARM_ARCH 7
347:#define __ARM_ARCH_7A__ 1

[XadillaX]

I think it's due to gcc. The arm version can't be gotten from gcc.

[silverwind]

Maybe it's because your binary was built on armv6?

[XadillaX]

I'm not sure. GCC is installed at the very beginning in the image of Raspbian.

[silverwind]

What does /proc/cpuinfo show? Here's mine:

processor	: 0
model name	: ARMv7 Processor rev 4 (v7l)
BogoMIPS	: 38.40
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xd03
CPU revision	: 4

[XadillaX]

@silverwind same with yours. Mine is RPi3 too.

[silverwind]

Weird, I have no idea except that maybe gcc is out of date.

[bnoordhuis]

Raspbian is ARMv6+VFP2. ARMv7+ binaries don't work on it, as far as I'm aware; install Debian/armhf for that.

[XadillaX]

@silverwind I think so too. So my suggestion is that we can't get arm version from GCC.

[bnoordhuis]

I'll close this out. Per the discussion, there is no support for changing process.arch.

The process.config.variables.arm_version thing is being tracked in nodejs/build#897.