CI: https://ci.nodejs.org/job/node-test-pull-request/30702/

Not running a V8 CI yet, because the V8 CI is currently broken.

cc @nodejs/platform-freebsd @nodejs/platform-smartos build is failing on both platforms with similar error:

FreeBSD:

16:25:34 ../deps/v8/src/base/platform/platform-freebsd.cc:104:11: error: use of undeclared identifier 'pthread_attr_get_np'; did you mean 'pthread_attr_getscope'?
16:25:34   error = pthread_attr_get_np(pthread_self(), &attr);
16:25:34           ^~~~~~~~~~~~~~~~~~~
16:25:34           pthread_attr_getscope
16:25:34 /usr/include/pthread.h:312:6: note: 'pthread_attr_getscope' declared here
16:25:34 int             pthread_attr_getscope(const pthread_attr_t *, int *);
16:25:34                 ^
16:25:34 ../deps/v8/src/base/platform/platform-freebsd.cc:104:31: error: cannot initialize a parameter of type 'const pthread_attr_t *' (aka 'pthread_attr *const *') with an rvalue of type 'pthread_t' (aka 'pthread *')
16:25:34   error = pthread_attr_get_np(pthread_self(), &attr);
16:25:34                               ^~~~~~~~~~~~~~
16:25:34 /usr/include/pthread.h:312:50: note: passing argument to parameter here
16:25:34 int             pthread_attr_getscope(const pthread_attr_t *, int *);
16:25:34                                                             ^
16:25:34 2 errors generated.

SmartOS:

16:26:58 ../deps/v8/src/base/platform/platform-posix.cc: In static member function 'static void* v8::base::Stack::GetStackStart()':
16:26:58 ../deps/v8/src/base/platform/platform-posix.cc:978:15: error: 'pthread_getattr_np' was not declared in this scope
16:26:58    int error = pthread_getattr_np(pthread_self(), &attr);
16:26:58                ^~~~~~~~~~~~~~~~~~
16:26:58 ../deps/v8/src/base/platform/platform-posix.cc:978:15: note: suggested alternative: 'pthread_getname_np'
16:26:58    int error = pthread_getattr_np(pthread_self(), &attr);
16:26:58                ^~~~~~~~~~~~~~~~~~
16:26:58                pthread_getname_np
16:26:58 make[2]: *** [tools/v8_gypfiles/v8_libbase.target.mk:147: /home/iojs/build/workspace/node-test-commit-smartos/nodes/smartos18-64/out/Release/obj.target/v8_libbase/deps/v8/src/base/platform/platform-posix.o] Error 1

Diff in deps/v8/includes: https://gist.github.com/targos/196ca29dd29e719191fc70e02c5de68c

Is there anything breaking the ABI that we want to backport to 8.2 8.1 so it goes it out with Node.js 14?

@targos Yeah, there’s a number of ABI-breaking changes… do we ship 14.0.0 with V8 8.2?

@addaleax no, sorry I meant V8 8.1. The diff I posted is between current master (8.1) and the PR (8.3).

And my question is: are there ABI-breaking changes that we should rather somehow port to V8 8.1 before v14.0.0 is released because it will be cumbersome to revert them when we want to backport the upgrade to V8 8.3?

If we get a forward patch for the ABI breaking changes this weekend, will there be enough time for it to make into v14?

And my question is: are there ABI-breaking changes that we should rather somehow port to V8 8.1 before v14.0.0 is released because it will be cumbersome to revert them when we want to backport the upgrade to V8 8.3?

Yes. Of the ABI-breaking changes, you’d want to patch them to be as close to V8 8.3 as possible, with as few exceptions as possible.

If we get a forward patch for the ABI breaking changes this weekend, will there be enough time for it to make into v14?

I should be able to put something like that together, if that’s desired. I guess whether that leaves enough time depends on what @BethGriggs says?

I can pull updates into the release up until Monday. I'd assume the update would be semver-major, so it'd also need no objections from TSC to land. I have slight concerns that this patch wouldn't have much time to live on master, but will defer judgement to those more familiar with V8 updates/internals. tldr; I can land the update if it's on master by Monday, assuming no objections from the TSC.

@BethGriggs That patch wouldn’t go on master, though (at least that’s what we’ve done in the past, I think). It would target v14.x-staging directly, and not be semver-major there, since no previous v14.x release exists.

@addaleax let me know if there's anything I can help with the patch.

@mmarchini can you cherry-pick cjihrig@fb9e01d as a proposed fix for SmartOS. I started a CI run with that change, and the SmartOS build compiled and the tests passed.

@mmarchini V8 8.3 was officially announced today: https://v8.dev/blog/v8-release-83

Will you have time to update this? Otherwise I can try to do it tomorrow

@targos I'll try to update it today, otherwise feel free to update tomorrow. (I definitely lost track of time and missed the start of May lol)

@targos I won't have time to do it today. Feel free to do it tomorrow. If you don't have time I think I can get to it by the end of the week.

@nodejs/testing test.parallel/test-https-foafssl failed twice in a row. Is it a known flake?

Sorry, wrong thread

CI: https://ci.nodejs.org/job/node-test-pull-request/31175/
V8: https://ci.nodejs.org/job/node-test-commit-v8-linux/3093/

/cc @nodejs/platform-freebsd

09:46:16 ../deps/v8/src/base/platform/platform-freebsd.cc:104:11: error: use of undeclared identifier 'pthread_attr_get_np'; did you mean 'pthread_attr_getscope'?
09:46:16   error = pthread_attr_get_np(pthread_self(), &attr);
09:46:16           ^~~~~~~~~~~~~~~~~~~
09:46:16           pthread_attr_getscope
09:46:16 /usr/include/pthread.h:312:6: note: 'pthread_attr_getscope' declared here
09:46:16 int             pthread_attr_getscope(const pthread_attr_t *, int *);
09:46:16                 ^
09:46:16 ../deps/v8/src/base/platform/platform-freebsd.cc:104:31: error: cannot initialize a parameter of type 'const pthread_attr_t *' (aka 'pthread_attr *const *') with an rvalue of type 'pthread_t' (aka 'pthread *')
09:46:16   error = pthread_attr_get_np(pthread_self(), &attr);
09:46:16                               ^~~~~~~~~~~~~~
09:46:16 /usr/include/pthread.h:312:50: note: passing argument to parameter here
09:46:16 int             pthread_attr_getscope(const pthread_attr_t *, int *);
09:46:16                                                             ^
09:46:16 2 errors generated.
09:46:16 gmake[2]: *** [tools/v8_gypfiles/v8_libbase.target.mk:156: /usr/home/iojs/build/workspace/node-test-commit-freebsd/nodes/freebsd11-x64/out/Release/obj.target/v8_libbase/deps/v8/src/base/platform/platform-freebsd.o] Error 1

@nodejs/platform-ppc @nodejs/platform-ibmi @nodejs/platform-aix (I don't know which team is relevant to LinuxONE)

It looks like --interpreted-frames-native-stack is no longer supported by V8 on that platform: https://ci.nodejs.org/job/node-test-commit-linuxone/20771/nodes=rhel7-s390x/testReport/junit/(root)/test/parallel_test_cli_node_options/
Is it a known limitation?

Ah, I think that's @nodejs/platform-s390, sorry for the ping, other teams.

Refs: https://github.com/v8/v8/blob/843c8de8238184aa9fa856ca3673b457424c1457/src/flags/flag-definitions.h#L1641-L1651

The flag is now excluded for ARM and S390X.

Should I skip the test if process.arch === 's390x' ?

@targos yes s390 has the same issue Arm had experienced in which relative offsets in memory cannot exceed 32 bits, there are no instructions for supporting it.

@targos the issue mentioned in this comment is now resolved in V8 master. S390 tests can be re-enabled in the next update. Let me know if changes need to be backported.

@targos Hello, we need to re-enable the test skipped in this comment on s390, and to do so need to have these two CLs ported to nodejs:
https://chromium-review.googlesource.com/c/v8/v8/+/2196521
https://chromium-review.googlesource.com/c/v8/v8/+/2193911

Should I open a backport to nodejs master?

@miladfarca Hi. It depends on whether it's important to land the changes sooner on v14.x. #33579 already includes them but won't land in a release at least before July 14.

@targos It think it would be safer to land them sooner, should I backport to master or v14.x-staging?

Master is fine

@targos Thanks, here is the PR: #33702