deps: update V8 to 14.8

[targos]

This is not intended to replace #61898, but I'm opening it early so we can hopefully work together to fix it in time for Node.js 26.0.0

[nodejs-github-bot]

Review requested:

• @nodejs/gyp
• @nodejs/security-wg
• @nodejs/v8-update

[targos]

Build with postmortem support is broken, and 4a0d16e was not enough to fix it, so I disabled it in f1e0d4c to go further. /cc @nodejs/post-mortem

[targos]

If I apply the above fix, it fails at node_mksnapshot and I think it's related to v8#245
/cc @joyeecheung

[joyeecheung]

I was trying to update to lkgr (14.9.5) in this branch in order to fix canary, I got node_mksnapshot compiled on GCC 13.3 on x64 Linux and then I hit the snapshot issue.

• Disabling v8_postmortem_support: I think all consumers of this (in the org, mostly llnode) are no longer maintained. It should be fine to drop it. New plugins should use V8's debug helper library instead.
• The wasm-shuffle-reducer.cc fix: yes, that's the right way to fix it.
• There are a bunch of unqualified std::nullptr_t, I fixed it in this commit in my branch (not sure if it is not yet in 14.8)
• There's a missing include in bigint.h that I fixed in this commit
• Some real gyp conditions will be needed to mimic https://chromium-review.googlesource.com/c/v8/v8/+/7683553, I put it in this commit

The snapshot issue is platform independent. I will need to check with the upstream to see what's the path forward (AFAICT, we don't support the configuration where the issue described v8#245 is relevant, maybe we can tweak it differently under the configuration we do build with).

[targos]

I already pushed a few fixes that I identified by looking at the GH Actions logs. Feel free to push more and/or upstream some stuff. I'll be away for a week.

[joyeecheung]

Upstreamed the libstdc++/gcc patches for the canary to pick it up sooner:

https://chromium-review.googlesource.com/c/v8/v8/+/7726129
https://chromium-review.googlesource.com/c/v8/v8/+/7726130
https://chromium-review.googlesource.com/c/v8/v8/+/7726131

Also updated the canary-base branch to include the v8_postmortem_support disabling and arch-specific gyp conditions

[richardlau]

FWIW I ran a V8 CI on the earlier beff131 commit and that failed on Linux ppc64le and s390x with
e.g. https://ci.nodejs.org/job/node-test-commit-v8-linux/7118/nodes=rhel8-s390x,v8test=v8test/console

12:46:06 ERROR at //build/toolchain/gcc_toolchain.gni:711:18: Assignment had no effect.
12:46:06         inputs = rustc_wrapper_inputs
12:46:06                  ^-------------------
12:46:06 You set the variable "inputs" here and it was unused before it went
12:46:06 out of scope.
12:46:06 
12:46:06 Via these template invocations:
12:46:06   clang_toolchain("clang_ppc64")  //build/toolchain/linux/BUILD.gn:11
12:46:06   gcc_toolchain("clang_ppc64")  //build/toolchain/gcc_toolchain.gni:929
12:46:06   single_gcc_toolchain("clang_ppc64")  //build/toolchain/gcc_toolchain.gni:894
12:46:06 
12:46:06 See //build/toolchain/gcc_toolchain.gni:894:3: whence it was called.
12:46:06   single_gcc_toolchain(target_name) {
12:46:06   ^----------------------------------
12:46:06 See //build/toolchain/gcc_toolchain.gni:929:3: whence it was called.
12:46:06   gcc_toolchain(target_name) {
12:46:06   ^---------------------------
12:46:06 See //build/toolchain/linux/BUILD.gn:11:1: whence it was called.
12:46:06 clang_toolchain("clang_ppc64") {
12:46:06 ^-------------------------------
12:46:06 See //BUILD.gn:2406:3: which caused the file to be included.
12:46:06   action("run_torque" + suffix) {
12:46:06   ^------------------------------
12:46:06 Loading //third_party/zlib/BUILD.gn (referenced from //BUILD.gn:6868)
12:46:06 make: *** [Makefile:317: v8] Error 1

We think we might need a newer version of gn, so I've been working on that.
With 4684d41 and updated gn, we have failures,
e.g. https://ci.nodejs.org/job/node-test-commit-v8-linux/7142/nodes=rhel8-s390x,v8test=v8test/console

16:00:33 clang++: error: unknown argument: '-fno-lifetime-dse'
16:00:33 clang++: error: unknown argument: '-fsanitize-ignore-for-ubsan-feature=array-bounds'
16:00:33 clang++: error: unknown argument: '-fsanitize-ignore-for-ubsan-feature=return'

which are due to the version of clang we're using (19) not supporting those arguments.

On Linux ppc64le and s390x for upstream V8 the gn build files are being patched to remove compiler args that clang 19/20 does not support:
https://github.com/ibmruntimes/v8-build/blob/cda03de00a0a6a5fb04958e51ae365c78dcb379b/bin/v8.sh#L62-L71

we'll probably need to translate that into tools/make-v8.sh as it'll need to be patched out after tools/v8/fetch_deps.py is run. I can look at that after I finish updating the machines (updated gn and Java 25).

[richardlau]

hmm. Okay for the V8 CI on Linux ppc64le and s390x with V8 14.8 we need to bump Rust (to 1.88) as per nodejs/build#4265 (which drags with it a bump to clang 20 since both depend on llvm).
https://ci.nodejs.org/job/node-test-commit-v8-linux/7147/nodes=rhel8-s390x,v8test=v8test/console

15:29:19 [39/2471] ln -f clang_s390x_for_rust_host_build_tools/obj/build/rust/std/libadler2.rlib clang_s390x_for_rust_host_build_tools/prebuilt_rustc_sysroot/lib/rustlib/s390x-unknown-linux-gnu/lib/libadler2.rlib 2>/dev/null || (rm -rf clang_s390x_for_rust_host_build_tools/prebuilt_rustc_sysroot/lib/rustlib/s390x-unknown-linux-gnu/lib/libadler2.rlib && cp -af clang_s390x_for_rust_host_build_tools/obj/build/rust/std/libadler2.rlib clang_s390x_for_rust_host_build_tools/prebuilt_rustc_sysroot/lib/rustlib/s390x-unknown-linux-gnu/lib/libadler2.rlib)
15:29:19 FAILED: [code=1] clang_s390x_for_rust_host_build_tools/prebuilt_rustc_sysroot/lib/rustlib/s390x-unknown-linux-gnu/lib/libadler2.rlib 
15:29:19 ln -f clang_s390x_for_rust_host_build_tools/obj/build/rust/std/libadler2.rlib clang_s390x_for_rust_host_build_tools/prebuilt_rustc_sysroot/lib/rustlib/s390x-unknown-linux-gnu/lib/libadler2.rlib 2>/dev/null || (rm -rf clang_s390x_for_rust_host_build_tools/prebuilt_rustc_sysroot/lib/rustlib/s390x-unknown-linux-gnu/lib/libadler2.rlib && cp -af clang_s390x_for_rust_host_build_tools/obj/build/rust/std/libadler2.rlib clang_s390x_for_rust_host_build_tools/prebuilt_rustc_sysroot/lib/rustlib/s390x-unknown-linux-gnu/lib/libadler2.rlib)
15:29:19 cp: cannot stat 'clang_s390x_for_rust_host_build_tools/obj/build/rust/std/libadler2.rlib': No such file or directory

I think doing that will break the V8 CI for V8 14.6, so I'm not inclined to update until we land 14.6 first (unless @targos believes we skip 14.6 and go to this one). This is a limitation with the way the V8 gn build builds the rust crates. AFAIK the gyp-based Node.js build can build the crates with a much wider range of Rust versions.

Unfortunately we cannot have two different versions of rust installed on RHEL from dnf and if possible I would like to avoid installing rust outside of the package manager on the machines we manage.

[targos]

I'm going to land 14.6 as soon as CI is green.

[richardlau]

On Linux ppc64le and s390x for upstream V8 the gn build files are being patched to remove compiler args that clang 19/20 does not support: https://github.com/ibmruntimes/v8-build/blob/cda03de00a0a6a5fb04958e51ae365c78dcb379b/bin/v8.sh#L62-L71

we'll probably need to translate that into tools/make-v8.sh as it'll need to be patched out after tools/v8/fetch_deps.py is run. I can look at that after I finish updating the machines (updated gn and Java 25).

FWIW

diff --git a/tools/make-v8.sh b/tools/make-v8.sh
index bf74606e1908a3..425abea8da1d59 100755
--- a/tools/make-v8.sh
+++ b/tools/make-v8.sh
@@ -27,6 +27,14 @@ if [ "$ARCH" = "s390x" ] || [ "$ARCH" = "ppc64le" ]; then
     *) ;;
   esac
 
+  find build/ \( -name "*.gn" -o -name "*.gni" \) | xargs sed -i \
+    -e '/-Wno-unsafe-buffer-usage-in-static-sized-array/d' \
+    -e '/-Wno-uninitialized-const-pointer/d' \
+    -e '/-Wno-unused-but-set-global/d' \
+    -e '/-fno-lifetime-dse/d' \
+    -e '/-fsanitize-ignore-for-ubsan-feature/d' \
+    -e '/-fdiagnostics-show-inlining-chain/d'
+
   # shellcheck disable=SC2154
   case "$CXX" in
     *clang*)

For clang 19 we also need to erase -Wno-nontrivial-memcall (not in the ibmruntimes/v8-build repo as clang 20 is used there).

[targos]

@StefanStojanovic It looks like we have a new error on Windows: https://github.com/nodejs/node/actions/runs/25207691004/job/73911437967?pr=62572

[340](https://github.com/nodejs/node/actions/runs/25207691004/job/73911437967#step:7:5341)
..\..\deps\v8\src\runtime\runtime-test.cc(1176,27): error : no matching constructor for initialization of 'std::atomic_flag' [D:\a\node\node\tools\v8_gypfiles\v8_base_without_compiler.vcxproj]
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.44.35207\include\atomic(2799,20): message : candidate constructor (the implicit copy constructor) not viable: no known conversion from 'bool' to 'const atomic_flag' for 1st argument [D:\a\node\node\tools\v8_gypfiles\v8_base_without_compiler.vcxproj]
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.44.35207\include\atomic(2826,15): message : candidate constructor not viable: requires 0 arguments, but 1 was provided [D:\a\node\node\tools\v8_gypfiles\v8_base_without_compiler.vcxproj]

[joyeecheung]

I looked into the snapshot issue a bit and I think there are at least 4 options to resolve it:

1. Disable snapshot, but this would incur a significant startup performance regression
2. Float a revert of https://chromium-review.googlesource.com/c/v8/v8/+/7668829 for now: this is a patch to eliminate a V8 sandbox escape path which is not applicable to us because we don't even enable sandbox. I have a commit in my branch to revert it and address the conflicts, locally it compiles and pass most tests except some wasm tests which I think are unrelated (though we'd need to fix those as well for this upgrade)
3. To upstream it we could gate the old fast API call layout behind an ifndef V8_ENABLE_SANDBOX guard, then for Node.js which doesn't enable sandbox it will stay working. I'll upload a CL on Monday to see if the upstream would accept it.
4. Longer term we could just add proper serialization support for the new layout of fast API calls (possibly via callbacks, like what we do for internal fields/context embedder data).

[targos]

V8 CI: https://ci.nodejs.org/job/node-test-commit-v8-linux/7174/