build: generate the Node startup snapshot on cross-arch builds too - #52874

Node's GN build set NODE_ARCH to "ia32" whenever the toolchain compiling
it was x86 and to target_cpu otherwise. That is the same thing for a
normal build, but not in V8's snapshot toolchain: the arm (32-bit)
snapshot is produced by an x86-hosted node_mksnapshot, which therefore
carried NODE_ARCH="ia32", and since #52874 the arm build boots its main
process from that snapshot - so process.arch read "ia32" there while
renderers and workers said "arm". Spell the ia32 special case off
target_cpu instead, which is right in the target toolchain and in every
host toolchain that builds node for the snapshot.

…52874)

node_use_node_snapshot / node_use_node_code_cache were gated to
host_cpu == target_cpu, so the targets Electron cross-builds -- linux
arm64 and win arm64 (x64 hosts) and mac x64 (arm64 hosts) -- shipped
without the embedded Node snapshot and its builtin code cache, and every
process there still ran the full Node bootstrap.

node_mksnapshot already builds in v8_snapshot_toolchain, like mksnapshot
and v8_context_snapshot_generator. Unlike those it executes target-CPU
code (the Node bootstrap runs in JS), so the requirement is a snapshot
toolchain that can run what its V8 emits: V8's arm64 simulator on x64
hosts (linux clang_x64_v8_arm64, the win host toolchain with
v8_target_cpu = arm64), or an x64 binary under Rosetta on arm64 macs,
which is what Electron CI's v8_snapshot_toolchain =
"//build/toolchain/mac:clang_x64" override for mac x64 already provides.
The one same-OS combination that cannot work is V8's default for mac
arm64 -> x64, clang_arm64_v8_x64 (arm64 binary emitting x64 code, no
simulator) -- that is the crash the old TODO in node.gni described.
Neither the snapshot nor the code cache contains machine code, so what a
cross node_mksnapshot produces is valid on the target; the js2c code
cache is already generated cross-arch the same way.

So gate both on host_os == target_os except that toolchain, and give the
node_snapshot / node_snapshot_stub source_sets the
//base:debugging_buildflags dependency that node_builtins.h's
base/dcheck_is_on.h include needs (a fresh out dir building only
third_party/electron_node:node_snapshot failed on the missing generated
header). Also brings the patch description up to date.

Verified on a linux x64 host with target_cpu = "arm64": node_mksnapshot
runs under the simulator (blob 4.9 MB, 392-entry / 2.8 MB code cache, same
shape as native), the snapshot-keyed browser js2c cache tool runs, and
electron links with the snapshot embedded. Booting it needs arm64
hardware; the js2c code-cache spec's browser assertions and
process.config.variables.node_use_node_snapshot cover it on the arm64
test legs. mac x64 and win arm64 are by construction, untested locally.

(cherry picked from commit cbb5e25)

Node's GN build set NODE_ARCH to "ia32" whenever the toolchain compiling
it was x86 and to target_cpu otherwise. That is the same thing for a
normal build, but not in V8's snapshot toolchain: the arm (32-bit)
snapshot is produced by an x86-hosted node_mksnapshot, which therefore
carried NODE_ARCH="ia32", and since #52874 the arm build boots its main
process from that snapshot - so process.arch read "ia32" there while
renderers and workers said "arm". Spell the ia32 special case off
target_cpu instead, which is right in the target toolchain and in every
host toolchain that builds node for the snapshot.

…52874)

node_use_node_snapshot / node_use_node_code_cache were gated to
host_cpu == target_cpu, so the targets Electron cross-builds -- linux
arm64 and win arm64 (x64 hosts) and mac x64 (arm64 hosts) -- shipped
without the embedded Node snapshot and its builtin code cache, and every
process there still ran the full Node bootstrap.

node_mksnapshot already builds in v8_snapshot_toolchain, like mksnapshot
and v8_context_snapshot_generator. Unlike those it executes target-CPU
code (the Node bootstrap runs in JS), so the requirement is a snapshot
toolchain that can run what its V8 emits: V8's arm64 simulator on x64
hosts (linux clang_x64_v8_arm64, the win host toolchain with
v8_target_cpu = arm64), or an x64 binary under Rosetta on arm64 macs,
which is what Electron CI's v8_snapshot_toolchain =
"//build/toolchain/mac:clang_x64" override for mac x64 already provides.
The one same-OS combination that cannot work is V8's default for mac
arm64 -> x64, clang_arm64_v8_x64 (arm64 binary emitting x64 code, no
simulator) -- that is the crash the old TODO in node.gni described.
Neither the snapshot nor the code cache contains machine code, so what a
cross node_mksnapshot produces is valid on the target; the js2c code
cache is already generated cross-arch the same way.

So gate both on host_os == target_os except that toolchain, and give the
node_snapshot / node_snapshot_stub source_sets the
//base:debugging_buildflags dependency that node_builtins.h's
base/dcheck_is_on.h include needs (a fresh out dir building only
third_party/electron_node:node_snapshot failed on the missing generated
header). Also brings the patch description up to date.

Verified on a linux x64 host with target_cpu = "arm64": node_mksnapshot
runs under the simulator (blob 4.9 MB, 392-entry / 2.8 MB code cache, same
shape as native), the snapshot-keyed browser js2c cache tool runs, and
electron links with the snapshot embedded. Booting it needs arm64
hardware; the js2c code-cache spec's browser assertions and
process.config.variables.node_use_node_snapshot cover it on the arm64
test legs. mac x64 and win arm64 are by construction, untested locally.

(cherry picked from commit cbb5e25)

Node's GN build set NODE_ARCH to "ia32" whenever the toolchain compiling
it was x86 and to target_cpu otherwise. That is the same thing for a
normal build, but not in V8's snapshot toolchain: the arm (32-bit)
snapshot is produced by an x86-hosted node_mksnapshot, which therefore
carried NODE_ARCH="ia32", and since #52874 the arm build boots its main
process from that snapshot - so process.arch read "ia32" there while
renderers and workers said "arm". Spell the ia32 special case off
target_cpu instead, which is right in the target toolchain and in every
host toolchain that builds node for the snapshot.

Node's GN build set NODE_ARCH to "ia32" whenever the toolchain compiling
it was x86 and to target_cpu otherwise. That is the same thing for a
normal build, but not in V8's snapshot toolchain: the arm (32-bit)
snapshot is produced by an x86-hosted node_mksnapshot, which therefore
carried NODE_ARCH="ia32", and since #52874 the arm build boots its main
process from that snapshot - so process.arch read "ia32" there while
renderers and workers said "arm". Spell the ia32 special case off
target_cpu instead, which is right in the target toolchain and in every
host toolchain that builds node for the snapshot.

Node's GN build set NODE_ARCH to "ia32" whenever the toolchain compiling
it was x86 and to target_cpu otherwise. That is the same thing for a
normal build, but not in V8's snapshot toolchain: the arm (32-bit)
snapshot is produced by an x86-hosted node_mksnapshot, which therefore
carried NODE_ARCH="ia32", and since #52874 the arm build boots its main
process from that snapshot - so process.arch read "ia32" there while
renderers and workers said "arm". Spell the ia32 special case off
target_cpu instead, which is right in the target toolchain and in every
host toolchain that builds node for the snapshot.

Node's GN build set NODE_ARCH to "ia32" whenever the toolchain compiling
it was x86 and to target_cpu otherwise. That is the same thing for a
normal build, but not in V8's snapshot toolchain: the arm (32-bit)
snapshot is produced by an x86-hosted node_mksnapshot, which therefore
carried NODE_ARCH="ia32", and since #52874 the arm build boots its main
process from that snapshot - so process.arch read "ia32" there while
renderers and workers said "arm". Spell the ia32 special case off
target_cpu instead, which is right in the target toolchain and in every
host toolchain that builds node for the snapshot.

fix: name node's arch after the target cpu in every toolchain

Node's GN build set NODE_ARCH to "ia32" whenever the toolchain compiling
it was x86 and to target_cpu otherwise. That is the same thing for a
normal build, but not in V8's snapshot toolchain: the arm (32-bit)
snapshot is produced by an x86-hosted node_mksnapshot, which therefore
carried NODE_ARCH="ia32", and since #52874 the arm build boots its main
process from that snapshot - so process.arch read "ia32" there while
renderers and workers said "arm". Spell the ia32 special case off
target_cpu instead, which is right in the target toolchain and in every
host toolchain that builds node for the snapshot.

…52874)

node_use_node_snapshot / node_use_node_code_cache were gated to
host_cpu == target_cpu, so the targets Electron cross-builds -- linux
arm64 and win arm64 (x64 hosts) and mac x64 (arm64 hosts) -- shipped
without the embedded Node snapshot and its builtin code cache, and every
process there still ran the full Node bootstrap.

node_mksnapshot already builds in v8_snapshot_toolchain, like mksnapshot
and v8_context_snapshot_generator. Unlike those it executes target-CPU
code (the Node bootstrap runs in JS), so the requirement is a snapshot
toolchain that can run what its V8 emits: V8's arm64 simulator on x64
hosts (linux clang_x64_v8_arm64, the win host toolchain with
v8_target_cpu = arm64), or an x64 binary under Rosetta on arm64 macs,
which is what Electron CI's v8_snapshot_toolchain =
"//build/toolchain/mac:clang_x64" override for mac x64 already provides.
The one same-OS combination that cannot work is V8's default for mac
arm64 -> x64, clang_arm64_v8_x64 (arm64 binary emitting x64 code, no
simulator) -- that is the crash the old TODO in node.gni described.
Neither the snapshot nor the code cache contains machine code, so what a
cross node_mksnapshot produces is valid on the target; the js2c code
cache is already generated cross-arch the same way.

So gate both on host_os == target_os except that toolchain, and give the
node_snapshot / node_snapshot_stub source_sets the
//base:debugging_buildflags dependency that node_builtins.h's
base/dcheck_is_on.h include needs (a fresh out dir building only
third_party/electron_node:node_snapshot failed on the missing generated
header). Also brings the patch description up to date.

Verified on a linux x64 host with target_cpu = "arm64": node_mksnapshot
runs under the simulator (blob 4.9 MB, 392-entry / 2.8 MB code cache, same
shape as native), the snapshot-keyed browser js2c cache tool runs, and
electron links with the snapshot embedded. Booting it needs arm64
hardware; the js2c code-cache spec's browser assertions and
process.config.variables.node_use_node_snapshot cover it on the arm64
test legs. mac x64 and win arm64 are by construction, untested locally.

(cherry picked from commit cbb5e25)

Node's GN build set NODE_ARCH to "ia32" whenever the toolchain compiling
it was x86 and to target_cpu otherwise. That is the same thing for a
normal build, but not in V8's snapshot toolchain: the arm (32-bit)
snapshot is produced by an x86-hosted node_mksnapshot, which therefore
carried NODE_ARCH="ia32", and since #52874 the arm build boots its main
process from that snapshot - so process.arch read "ia32" there while
renderers and workers said "arm". Spell the ia32 special case off
target_cpu instead, which is right in the target toolchain and in every
host toolchain that builds node for the snapshot.

…52879)

* build: generate the Node startup snapshot on cross-arch builds too

node_use_node_snapshot / node_use_node_code_cache were gated to
host_cpu == target_cpu, so the targets Electron cross-builds -- linux
arm64 and win arm64 (x64 hosts) and mac x64 (arm64 hosts) -- shipped
without the embedded Node snapshot and its builtin code cache, and every
process there still ran the full Node bootstrap.

node_mksnapshot already builds in v8_snapshot_toolchain, like mksnapshot
and v8_context_snapshot_generator. Unlike those it executes target-CPU
code (the Node bootstrap runs in JS), so the requirement is a snapshot
toolchain that can run what its V8 emits: V8's arm64 simulator on x64
hosts (linux clang_x64_v8_arm64, the win host toolchain with
v8_target_cpu = arm64), or an x64 binary under Rosetta on arm64 macs,
which is what Electron CI's v8_snapshot_toolchain =
"//build/toolchain/mac:clang_x64" override for mac x64 already provides.
The one same-OS combination that cannot work is V8's default for mac
arm64 -> x64, clang_arm64_v8_x64 (arm64 binary emitting x64 code, no
simulator) -- that is the crash the old TODO in node.gni described.
Neither the snapshot nor the code cache contains machine code, so what a
cross node_mksnapshot produces is valid on the target; the js2c code
cache is already generated cross-arch the same way.

So gate both on host_os == target_os except that toolchain, and give the
node_snapshot / node_snapshot_stub source_sets the
//base:debugging_buildflags dependency that node_builtins.h's
base/dcheck_is_on.h include needs (a fresh out dir building only
third_party/electron_node:node_snapshot failed on the missing generated
header). Also brings the patch description up to date.

Verified on a linux x64 host with target_cpu = "arm64": node_mksnapshot
runs under the simulator (blob 4.9 MB, 392-entry / 2.8 MB code cache, same
shape as native), the snapshot-keyed browser js2c cache tool runs, and
electron links with the snapshot embedded. Booting it needs arm64
hardware; the js2c code-cache spec's browser assertions and
process.config.variables.node_use_node_snapshot cover it on the arm64
test legs. mac x64 and win arm64 are by construction, untested locally.

Co-authored-by: Shelley Vohr <[email protected]>

* fix: generate the Node startup snapshot once per build

run_node_mksnapshot was instantiated in every toolchain that pulled in
":node_snapshot", so a cross build ran it twice: once in the default
toolchain for the shipped framework, once in v8_snapshot_toolchain for the
host tool that generates the browser process's js2c code cache. Two runs
are not guaranteed to produce the same snapshot, and on Windows they do
not, so the tool built its cache against a read-only heap the framework
never embedded and V8 rejected every entry at startup with a read-only
snapshot checksum mismatch - the browser process compiled browser_init,
utility_init and node_init from source instead.

Define the action only in the default toolchain and have each toolchain's
":node_snapshot" compile that one output, so the snapshot the cache is
keyed to is the snapshot the framework ships.

Notes: none
(cherry picked from commit 3c44687)

* fix: name node's arch after the target cpu in every toolchain

Node's GN build set NODE_ARCH to "ia32" whenever the toolchain compiling
it was x86 and to target_cpu otherwise. That is the same thing for a
normal build, but not in V8's snapshot toolchain: the arm (32-bit)
snapshot is produced by an x86-hosted node_mksnapshot, which therefore
carried NODE_ARCH="ia32", and since #52874 the arm build boots its main
process from that snapshot - so process.arch read "ia32" there while
renderers and workers said "arm". Spell the ia32 special case off
target_cpu instead, which is right in the target toolchain and in every
host toolchain that builds node for the snapshot.

---------

Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Shelley Vohr <[email protected]>

…3-x-y) (#52881)

* build: generate the Node startup snapshot on cross-arch builds too (#52874)

node_use_node_snapshot / node_use_node_code_cache were gated to
host_cpu == target_cpu, so the targets Electron cross-builds -- linux
arm64 and win arm64 (x64 hosts) and mac x64 (arm64 hosts) -- shipped
without the embedded Node snapshot and its builtin code cache, and every
process there still ran the full Node bootstrap.

node_mksnapshot already builds in v8_snapshot_toolchain, like mksnapshot
and v8_context_snapshot_generator. Unlike those it executes target-CPU
code (the Node bootstrap runs in JS), so the requirement is a snapshot
toolchain that can run what its V8 emits: V8's arm64 simulator on x64
hosts (linux clang_x64_v8_arm64, the win host toolchain with
v8_target_cpu = arm64), or an x64 binary under Rosetta on arm64 macs,
which is what Electron CI's v8_snapshot_toolchain =
"//build/toolchain/mac:clang_x64" override for mac x64 already provides.
The one same-OS combination that cannot work is V8's default for mac
arm64 -> x64, clang_arm64_v8_x64 (arm64 binary emitting x64 code, no
simulator) -- that is the crash the old TODO in node.gni described.
Neither the snapshot nor the code cache contains machine code, so what a
cross node_mksnapshot produces is valid on the target; the js2c code
cache is already generated cross-arch the same way.

So gate both on host_os == target_os except that toolchain, and give the
node_snapshot / node_snapshot_stub source_sets the
//base:debugging_buildflags dependency that node_builtins.h's
base/dcheck_is_on.h include needs (a fresh out dir building only
third_party/electron_node:node_snapshot failed on the missing generated
header). Also brings the patch description up to date.

Verified on a linux x64 host with target_cpu = "arm64": node_mksnapshot
runs under the simulator (blob 4.9 MB, 392-entry / 2.8 MB code cache, same
shape as native), the snapshot-keyed browser js2c cache tool runs, and
electron links with the snapshot embedded. Booting it needs arm64
hardware; the js2c code-cache spec's browser assertions and
process.config.variables.node_use_node_snapshot cover it on the arm64
test legs. mac x64 and win arm64 are by construction, untested locally.

(cherry picked from commit cbb5e25)

* fix: generate the Node startup snapshot once per build

run_node_mksnapshot was instantiated in every toolchain that pulled in
":node_snapshot", so a cross build ran it twice: once in the default
toolchain for the shipped framework, once in v8_snapshot_toolchain for the
host tool that generates the browser process's js2c code cache. Two runs
are not guaranteed to produce the same snapshot, and on Windows they do
not, so the tool built its cache against a read-only heap the framework
never embedded and V8 rejected every entry at startup with a read-only
snapshot checksum mismatch - the browser process compiled browser_init,
utility_init and node_init from source instead.

Define the action only in the default toolchain and have each toolchain's
":node_snapshot" compile that one output, so the snapshot the cache is
keyed to is the snapshot the framework ships.

Notes: none
(cherry picked from commit 3c44687)

* fix: name node's arch after the target cpu in every toolchain

Node's GN build set NODE_ARCH to "ia32" whenever the toolchain compiling
it was x86 and to target_cpu otherwise. That is the same thing for a
normal build, but not in V8's snapshot toolchain: the arm (32-bit)
snapshot is produced by an x86-hosted node_mksnapshot, which therefore
carried NODE_ARCH="ia32", and since #52874 the arm build boots its main
process from that snapshot - so process.arch read "ia32" there while
renderers and workers said "arm". Spell the ia32 special case off
target_cpu instead, which is right in the target toolchain and in every
host toolchain that builds node for the snapshot.

---------

Co-authored-by: Shelley Vohr <[email protected]>

…2-x-y) (#52880)

* build: generate the Node startup snapshot on cross-arch builds too (#52874)

node_use_node_snapshot / node_use_node_code_cache were gated to
host_cpu == target_cpu, so the targets Electron cross-builds -- linux
arm64 and win arm64 (x64 hosts) and mac x64 (arm64 hosts) -- shipped
without the embedded Node snapshot and its builtin code cache, and every
process there still ran the full Node bootstrap.

node_mksnapshot already builds in v8_snapshot_toolchain, like mksnapshot
and v8_context_snapshot_generator. Unlike those it executes target-CPU
code (the Node bootstrap runs in JS), so the requirement is a snapshot
toolchain that can run what its V8 emits: V8's arm64 simulator on x64
hosts (linux clang_x64_v8_arm64, the win host toolchain with
v8_target_cpu = arm64), or an x64 binary under Rosetta on arm64 macs,
which is what Electron CI's v8_snapshot_toolchain =
"//build/toolchain/mac:clang_x64" override for mac x64 already provides.
The one same-OS combination that cannot work is V8's default for mac
arm64 -> x64, clang_arm64_v8_x64 (arm64 binary emitting x64 code, no
simulator) -- that is the crash the old TODO in node.gni described.
Neither the snapshot nor the code cache contains machine code, so what a
cross node_mksnapshot produces is valid on the target; the js2c code
cache is already generated cross-arch the same way.

So gate both on host_os == target_os except that toolchain, and give the
node_snapshot / node_snapshot_stub source_sets the
//base:debugging_buildflags dependency that node_builtins.h's
base/dcheck_is_on.h include needs (a fresh out dir building only
third_party/electron_node:node_snapshot failed on the missing generated
header). Also brings the patch description up to date.

Verified on a linux x64 host with target_cpu = "arm64": node_mksnapshot
runs under the simulator (blob 4.9 MB, 392-entry / 2.8 MB code cache, same
shape as native), the snapshot-keyed browser js2c cache tool runs, and
electron links with the snapshot embedded. Booting it needs arm64
hardware; the js2c code-cache spec's browser assertions and
process.config.variables.node_use_node_snapshot cover it on the arm64
test legs. mac x64 and win arm64 are by construction, untested locally.

(cherry picked from commit cbb5e25)

* fix: generate the Node startup snapshot once per build

run_node_mksnapshot was instantiated in every toolchain that pulled in
":node_snapshot", so a cross build ran it twice: once in the default
toolchain for the shipped framework, once in v8_snapshot_toolchain for the
host tool that generates the browser process's js2c code cache. Two runs
are not guaranteed to produce the same snapshot, and on Windows they do
not, so the tool built its cache against a read-only heap the framework
never embedded and V8 rejected every entry at startup with a read-only
snapshot checksum mismatch - the browser process compiled browser_init,
utility_init and node_init from source instead.

Define the action only in the default toolchain and have each toolchain's
":node_snapshot" compile that one output, so the snapshot the cache is
keyed to is the snapshot the framework ships.

Notes: none
(cherry picked from commit 3c44687)

* fix: name node's arch after the target cpu in every toolchain

Node's GN build set NODE_ARCH to "ia32" whenever the toolchain compiling
it was x86 and to target_cpu otherwise. That is the same thing for a
normal build, but not in V8's snapshot toolchain: the arm (32-bit)
snapshot is produced by an x86-hosted node_mksnapshot, which therefore
carried NODE_ARCH="ia32", and since #52874 the arm build boots its main
process from that snapshot - so process.arch read "ia32" there while
renderers and workers said "arm". Spell the ia32 special case off
target_cpu instead, which is right in the target toolchain and in every
host toolchain that builds node for the snapshot.

---------

Co-authored-by: Shelley Vohr <[email protected]>