RISC-V to Experimental tier

[drom]

What is the problem this feature will solve?

Support growing number of RISC-V based devices

What is the feature you are proposing to solve the problem?

Provide RISC-V release of node-js

What alternatives have you considered?

No response

[Trott]

@nodejs/build @nodejs/releasers

[rvagg]

Without knowing enough about the current RISC-V landscape, it would be interesting to hear about distributions, operating systems and devices that are common. Are there lowest common denominators that we can leverage? Or is it a scattered landscape where we'd need to be shipping 5 different binaries to keep everyone happy? Already having musl as a competitor to glibc is slightly tricky to support on x64.

Beyond that - how would we test this in our CI system? Then how do we build binaries? Are we emulating everything? Is emulation a straightforward proposition? Are there any infra providers that might be convinced to provide RISC-V hardware?

If someone just wants to have a stab at it, you could try and contribute a recipe to unofficial-builds @ https://github.com/nodejs/unofficial-builds/; using a container on x64 to cross-compile a binary to RISC-V somehow. That'd probably be where such a binary would end up without significant CI and people resources anyway.

[drom]

Hi @rvagg great to hear from you.

Without knowing enough about the current RISC-V landscape, it would be interesting to hear about distributions, operating systems and devices that are common. Are there lowest common denominators that we can leverage? Or is it a scattered landscape where we'd need to be shipping 5 different binaries to keep everyone happy? Already having musl as a competitor to glibc is slightly tricky to support on x64.

Major Linux distributions declared RISC-V support: openSUSE, Debian/Ubuntu, Arch, Gentoo, Fedora,...

Most of them converges on: RV64GC baseline.

Beyond that - how would we test this in our CI system? Then how do we build binaries? Are we emulating everything? Is emulation a straightforward proposition? Are there any infra providers that might be convinced to provide RISC-V hardware?

I represent SiFive and we would gladly provide real Hardware for regression and CI here is the platform: https://www.sifive.com/boards/hifive-unmatched

If someone just wants to have a stab at it, you could try and contribute a recipe to unofficial-builds @ https://github.com/nodejs/unofficial-builds/; using a container on x64 to cross-compile a binary to RISC-V somehow. That'd probably be where such a binary would end up without significant CI and people resources anyway.

That is sounds awesome!

[sxa]

Hi @drom I'm very interested in this. The question would be how such boards could be hosted if we had them - do you have hosting for boards (Possibly via the PLCT lab?) or would you just be providing the hardware to the project that we'd have to host? Cross-compiling would likely be the preferred option with the testing completed on real boards, although with ccache enabled it could be done natively on the boards too in a reasonably timely manner (it's under 10 minutes for a "full" rebuild when the source hasn't changed using the onboard SD card for storage)

@rvagg I've used RISC-V systems with Ubuntu, Debian and Fedora and all of those are usable. As Aliaksei says there is a fairly good baseline that we can target for this that most boards that anyone would be likely to run on support so that shouldn't be a concern at this time. FYI I have previously built a RISC-V port of Node.js from https://github.com/v8-riscv/node on a SiFive Unleashed board that I have for another project so this is very much feasible (I just haven't had the cycles to push it forward since there's been little to drive it, but with SiFive's interest I'm sure we can make it happen and I'm very keen to help push it!)

[drom]

@sxa Great to hear from you.

Hi @drom I'm very interested in this. The question would be how such boards could be hosted if we had them - do you have hosting for boards (Possibly via the PLCT lab?) or would you just be providing the hardware to the project that we'd have to host?

We (SiFive) are open for any of these options. What ever is more convenient, comfortable for the Node project.
Sending some "Unmatched" boards to a specific location. We can host dedicated Nodes. I have dedicated board where I will be trying to run NodeJS right on my table, and can share. I just want this project to be successful.

Cross-compiling would likely be the preferred option with the testing completed on real boards, although with ccache enabled it could be done natively on the boards too in a reasonably timely manner (it's under 10 minutes for a "full" rebuild when the source hasn't changed using the onboard SD card for storage)

Great. I will try both options and report.

@rvagg I've used RISC-V systems with Ubuntu, Debian and Fedora and all of those are usable. As Aliaksei says there is a fairly good baseline that we can target for this that most boards that anyone would be likely to run on support so that shouldn't be a concern at this time. FYI I have previously built a RISC-V port of Node.js from https://github.com/v8-riscv/node on a SiFive Unleashed board that I have for another project so this is very much feasible (I just haven't had the cycles to push it forward since there's been little to drive it, but with SiFive's interest I'm sure we can make it happen and I'm very keen to help push it!)

Thank you for your help.

[sxa]

Great. I will try both options and report.

I'm also now trying to build the current nodejs/node master branch on my unleashed to see what state it's in

[sxa]

Great. I will try both options and report.

I'm also now trying to build the current nodejs/node master branch on my unleashed to see what state it's in

Took about eight hours to build on the unleashed board using --with-intl=none --verbose --without-node-snapshot --shared-openssl (Those were the options I used in the past - we'd likely want to make sure we can remove some of those before declaring a release, although I would imagine that wouldn't block us continuing as an unofficial build)

sxa@unleashed-sid:~/node-main$ ./node --version
v18.0.0-pre
sxa@unleashed-sid:~/node-main$

[sxa]

Also builds ok natively in about ten hours with just --shared-openssl from those above options, which is good.
Attempting to build with the mebedded openssl fails due to it trying to use invalid compiler options:

cc: error: unrecognized command-line option '-m64'

but a shared openssl for a first pass shouldn't be too much of a problem :-)

For reference, a sample command line being used for the attempt at compiling openssl is as follows - it has configured itself for x64 instead of riscv64 which probably isn't too hard to resolve: cc -o /home/sxa/node-main/out/Release/obj.target/openssl/deps/openssl/openssl/ssl/bio_ssl.o ../deps/openssl/openssl/ssl/bio_ssl.c '-DV8_DEPRECATION_WARNINGS' '-DV8_IMMINENT_DEPRECATION_WARNINGS' '-D_GLIBCXX_USE_CXX11_ABI=1' '-DNODE_OPENSSL_HAS_QUIC' '-D__STDC_FORMAT_MACROS' '-DOPENSSL_NO_PINSHARED' '-DOPENSSL_THREADS' '-DOPENSSL_NO_HW' '-DOPENSSL_API_COMPAT=0x10100001L' '-DSTATIC_LEGACY' '-DNDEBUG' '-DOPENSSL_USE_NODELETE' '-DL_ENDIAN' '-DOPENSSL_BUILDING_OPENSSL' '-DAES_ASM' '-DBSAES_ASM' '-DCMLL_ASM' '-DECP_NISTZ256_ASM' '-DGHASH_ASM' '-DKECCAK1600_ASM' '-DMD5_ASM' '-DOPENSSL_BN_ASM_GF2m' '-DOPENSSL_BN_ASM_MONT' '-DOPENSSL_BN_ASM_MONT5' '-DOPENSSL_CPUID_OBJ' '-DOPENSSL_IA32_SSE2' '-DPADLOCK_ASM' '-DPOLY1305_ASM' '-DSHA1_ASM' '-DSHA256_ASM' '-DSHA512_ASM' '-DVPAES_ASM' '-DWHIRLPOOL_ASM' '-DX25519_ASM' '-DOPENSSL_PIC' '-DMODULESDIR="/home/sxa/node-main/out/Release/obj.target/deps/openssl/lib/openssl-modules"' '-DOPENSSLDIR="/home/sxa/node-main/out/Release/obj.target/deps/openssl"' '-DENGINESDIR="/dev/null"' '-DTERMIOS' -I../deps/openssl/openssl -I../deps/openssl/openssl/include -I../deps/openssl/openssl/crypto -I../deps/openssl/openssl/crypto/include -I../deps/openssl/openssl/crypto/modes -I../deps/openssl/openssl/crypto/ec/curve448 -I../deps/openssl/openssl/crypto/ec/curve448/arch_32 -I../deps/openssl/openssl/providers/common/include -I../deps/openssl/openssl/providers/implementations/include -I../deps/openssl/config -I../deps/openssl/config/archs/linux-x86_64/asm -I../deps/openssl/config/archs/linux-x86_64/asm/include -I../deps/openssl/config/archs/linux-x86_64/asm/crypto -I../deps/openssl/config/archs/linux-x86_64/asm/crypto/include/internal -I../deps/openssl/config/archs/linux-x86_64/asm/providers/common/include -pthread -Wall -Wextra -Wno-unused-parameter -Wa,--noexecstack -Wall -O3 -pthread -m64 -Wall -O3 -Wno-missing-field-initializers -Wno-old-style-declaration -O3 -fno-omit-frame-pointer -MMD -MF /home/sxa/node-main/out/Release/.deps//home/sxa/node-main/out/Release/obj.target/openssl/deps/openssl/openssl/ssl/bio_ssl.o.d.raw -c

[luyahan]

v16.x and v17.x can build. but 17.x ocurs large segment fault. May be some patch of v8 not merge.

[drom]

Also builds ok natively in about ten hours with just --shared-openssl from those above options, which is good.

Wow. @sxa you just killing it! 👍
When you say "natively" is it on x86-64 or in RV64 QEMU?

[sxa]

Wow. @sxa you just killing it! +1 When you say "natively" is it on x86-64 or in RV64 QEMU?

Neither :-) It's on an Unleashed board that I have access to for another project (so sadly no M.2 drives unlike the Unmatched ones). I've used an RV64 qemu in the past but that would take days to build Node.js I expect!

[mmarchini]

I moved the issue to nodejs/build as I think it's the most relevant repository to continue this discussion (since there'll be work around setting up infrastructure). As discussed on Slack we can start with setting up one Jenkins agent and having a test job running on it. Once we have that setup we can discuss how many nodes would be convenient for both the Node.js project and for SiFive.

Question for @nodejs/build-infra: would we prefer RISC-V nodes being hosted by SiFive, or do we want to host those ourselves?

[sxa]

Assuming we'd have full access to them I think having it hosted by SiFive would generally be the preferred option assuming we had full access to it, although I could probably host one too.
My concern would be that I'm not sure it's possible to recover the Unmatched boards if they crash for whatever reason without someone physically pushing the reset button on them unlike most cloud machines so if we had any issues with it that could be a problem.

[rvagg]

Managed hosting where we have reason to trust the provider is the preferred option, by far. I've tried to minimise our reliance on infra hosted by individuals wherever possible and it would be good to reduce that even further over time.

Let's try and avoid signing up our infra for more boxes on desks. It's a big weak point in terms of reliability and, to some degree security.

[sxa]

Also builds ok natively in about ten hours with just --shared-openssl

A brief update on this - while it does build ok with the ICU support, it does seem to get stuck when building the test-doc target, so the ICU support is probably not working correctly on this platform.

[sxa]

I'm looking to get this building with a cross-compiler although I'm currently getting compiler failures when doing so. This PR doesn't resolve the issue I'm seeing. I'm going to build natively on the RISC-V board to see if it's a specific issue with the cross compile. If it can be convinced to work (and it should do) then we can likely get it added as an unofficial build using the existing system fairly quickly afterwards.

[sxa]

I've got a clean build with a cross compiler now so we should be able to incorporate this into a suitable dockerfile now. I've got one based on the arm_cross Dockerfile that will do the job using a tarball of a cross-compiler I use elsewhere for now.

[sxa]

"Unofficial build" support is now live (although the server that's building is is creaking a bit under space limitations) so we have builds at https://unofficial-builds.nodejs.org/download/release/v17.9.0/ so we just need to get that formalised in the docs.

The builds don't pass all the tests (mainly failures in crypto - perhaps due to openssl-no-asm - and addons tests) but it fundamentally works so I'm comfortable that it's good enough for experimental. It is built with full-icu (there's a version of 17.7.1 without ICU) so may well have an issue with the hangs described above with the doc target mentioned previously but we should consider whether we wish to perform some formal testing on this on real boards other than the ones I'm using elsewhere for now :-)

[rvagg]

fancy, good work @sxa .. I guess we need to deal with those space problems

[olof-nord]

I see RISC-V now included in the unofficial builds, great! Seems that the space issues from April are resolved.
What steps are needed, and what is the progress of, moving the RISC-V support from unofficial to official?

[sxa]

The next step would be to look at getting the build passing all the tests that come with node, since they weren't all passing last time I tried. SInce this is pretty much a spare time project for me I haven't had too much time to look at progressing that.

[sxa]

FYI There's a build break on 19.0.0 so there is no unofficial build for RISC-V in the latest version yet: nodejs/node#45059

[sxa]

Ref the last comment, 19.1.0 has RISC-V support back again at https://unofficial-builds.nodejs.org/download/release/v19.1.0/

While it's not part of the build pipelines yet (Performance would likely be an issue) I have connected in a RISC-V Ubuntu system into the CI and set up a job to build from the main branch daily and run the tests against it if any committers are interested in keeping an eye on it and/or fixing any failures. The job is at https://ci.nodejs.org/job/sxa-rvnodetest/ (On it's first run through as I write this but it should complete the build ok.

It would be good to get openssl support building without --openssl-no-asm at some point.

[sxa]

Additionally there are a few issues in the testing outside the main set of tests:

Linter checks:

Oops! Something went wrong! :(

ESLint: 8.28.0

/home/iojs/workspace/sxa-rvnodetest/tools/node_modules/eslint/node_modules/jsdoc-type-pratt-parser/dist/index.js:94
    const identifierStartRegex = /[$_\p{ID_Start}]|\\u\p{Hex_Digit}{4}|\\u\{0*(?:\p{Hex_Digit}{1,5}|10\p{Hex_Digit}{4})\}/u;
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

SyntaxError: Invalid regular expression: /[$_\p{ID_Start}]|\\u\p{Hex_Digit}{4}|\\u\{0*(?:\p{Hex_Digit}{1,5}|10\p{Hex_Digit}{4})\}/: Invalid property name in character class

Doc related tests

=== release test-doctool-html ===
Path: doctool/test-doctool-html
/home/iojs/workspace/sxa-rvnodetest/tools/doc/node_modules/highlight.js/lib/languages/xml.js:18
  const TAG_NAME_RE = regex.concat(/[\p{L}_]/u, regex.optional(/[\p{L}0-9_.-]*:/u), /[\p{L}0-9_.-]*/u);
                                   ^^^^^^^^^^^

SyntaxError: Invalid regular expression: /[\p{L}_]/: Invalid property name in character class
    at internalCompileFunction (node:internal/vm:74:18)

test-make-doc failure:

=== release test-make-doc ===
Path: doctool/test-make-doc
node:internal/process/esm_loader:108
    internalBinding('errors').triggerUncaughtException(
                              ^

AssertionError [ERR_ASSERTION]: false == true
    at file:///home/iojs/workspace/sxa-rvnodetest/test/doctool/test-make-doc.mjs:18:8
    at ModuleJob.run (node:internal/modules/esm/module_job:194:25) {
  generatedMessage: true,
  code: 'ERR_ASSERTION',
  actual: false,
  expected: true,
  operator: '=='
}

Node.js v20.0.0-pre
Command: out/Release/node /home/iojs/workspace/sxa-rvnodetest/test/doctool/test-make-doc.mjs

TracedValue.Escaping(Object|Array):

[ RUN      ] TracedValue.EscapingObject
../test/cctest/test_traced_value.cc:83: Failure
Expected equality of these values:
  check
    Which is: "{\"a\":\"1\\u00E2\\u0082\\u00AC23\\\"\\u0001\\b\\f\\n\\r\\t\\\\\"}"
  string
    Which is: "{\"a\":\"1\xE2\x82\xAC" "23\\\"\\u0001\\b\\f\\n\\r\\t\\\\\"}"
    As Text: "{"a":"1€23\"\u0001\b\f\n\r\t\\"}"
With diff:
@@ -1,1 +1,2 @@
-{\"a\":\"1\\u00E2\\u0082\\u00AC23\\\"\\u0001\\b\\f\\n\\r\\t\\\\\"}
+{\"a\":\"1\xE2\x82\xAC" "23\\\"\\u0001\\b\\f\\n\\r\\t\\\\\"}"
    As Text: "{"a":"1€23\"\u0001\b\f
+\r\t\\"}

[  FAILED  ] TracedValue.EscapingObject (0 ms)
[ RUN      ] TracedValue.EscapingArray
../test/cctest/test_traced_value.cc:95: Failure
Expected equality of these values:
  check
    Which is: "[\"1\\u00E2\\u0082\\u00AC23\\\"\\u0001\\b\\f\\n\\r\\t\\\\\"]"
  string
    Which is: "[\"1\xE2\x82\xAC" "23\\\"\\u0001\\b\\f\\n\\r\\t\\\\\"]"
    As Text: "["1€23\"\u0001\b\f\n\r\t\\"]"
With diff:
@@ -1,1 +1,2 @@
-[\"1\\u00E2\\u0082\\u00AC23\\\"\\u0001\\b\\f\\n\\r\\t\\\\\"]
+[\"1\xE2\x82\xAC" "23\\\"\\u0001\\b\\f\\n\\r\\t\\\\\"]"
    As Text: "["1€23\"\u0001\b\f
+\r\t\\"]

[  FAILED  ] TracedValue.EscapingArray (0 ms)

[richardlau]

@sxa I suspect those regexp failures are because you're compiling without ICU.

[olof-nord]

Great to list out the test errors, re the timeout adjustments there has been some work carried out by @ArchFeh already to accommodate less powerful riscv testing devices.

I looked into the OpenSSL assembly language optimisations for RISC-V, and there is some initial work for aes and modes/ghash in place, but I could not find it included in any release yet.

From what I can tell, Node.js additionally needs bn, chacha, ec, poly1305 as well as sha group (keccak1600, sha1, sha256 as well as sha512) asm for an architecture to be complete. Is that correct?

I do not know how much effort is needed here, but it looks like there is quite a lot of work left before this is done. Assuming all ciphers listed are needed, the current status is 20% (2 from 10) complete.

[sxa]

Yeah I hadn't realised when I wrote that statement earlier that the upstream openssl likely does not have the asm support in it, so that's not an issue that's specific to the Node.js build process (other than the fact we configure it by default without no-asm)

From what I can tell, Node.js additionally needs bn, chacha, ec, poly1305 as well as sha group (keccak1600, sha1, sha256 as well as sha512) asm for an architecture to be complete. Is that correct?

@richardlau @mhdawson Do you know if that is correct or if it can be considered a "complete" port while it's still using no-asm?

[richardlau]

Yeah I hadn't realised when I wrote that statement earlier that the upstream openssl likely does not have the asm support in it, so that's not an issue that's specific to the Node.js build process (other than the fact we configure it by default without no-asm)

From what I can tell, Node.js additionally needs bn, chacha, ec, poly1305 as well as sha group (keccak1600, sha1, sha256 as well as sha512) asm for an architecture to be complete. Is that correct?

@richardlau Do you know if that is correct or if it can be considered "complete" with no-asm?

No idea what you mean by "complete".

I'm not sure Node.js has a definitive list of supported algorithms -- you're likely to get a different set if using a binary from a Linux distro.

[sxa]

Additionally there are a few issues in the testing outside the main set of tests:

As @richardlau asserted most of these have gone away if I run with full-icu. Previously this was causing some hangs, but at least on my first run that is not happening. All of those failures in my second comment above pass with either small-icu or full-icu except for the linter:

make -s test-doc
Running JS linter...

Oops! Something went wrong! :(

ESLint: 8.28.0

TypeError: Cannot read properties of undefined (reading 'replace')
    at parse (/home/iojs/workspace/sxa-rvnodetest/tools/node_modules/eslint/lib/linter/linter.js:839:54)
    at Linter._verifyWithoutProcessors (/home/iojs/workspace/sxa-rvnodetest/tools/node_modules/eslint/lib/linter/linter.js:1349:33)
    at Linter._verifyWithConfigArray (/home/iojs/workspace/sxa-rvnodetest/tools/node_modules/eslint/lib/linter/linter.js:1769:21)
    at /home/iojs/workspace/sxa-rvnodetest/tools/node_modules/eslint/lib/linter/linter.js:1888:29
    at Array.map (<anonymous>)
    at Linter._verifyWithProcessor (/home/iojs/workspace/sxa-rvnodetest/tools/node_modules/eslint/lib/linter/linter.js:1868:37)
    at Linter._verifyWithConfigArray (/home/iojs/workspace/sxa-rvnodetest/tools/node_modules/eslint/lib/linter/linter.js:1762:25)
    at Linter.verify (/home/iojs/workspace/sxa-rvnodetest/tools/node_modules/eslint/lib/linter/linter.js:1476:65)
    at Linter.verifyAndFix (/home/iojs/workspace/sxa-rvnodetest/tools/node_modules/eslint/lib/linter/linter.js:2028:29)
    at verifyText (/home/iojs/workspace/sxa-rvnodetest/tools/node_modules/eslint/lib/cli-engine/cli-engine.js:245:48)
    at CLIEngine.executeOnFiles (/home/iojs/workspace/sxa-rvnodetest/tools/node_modules/eslint/lib/cli-engine/cli-engine.js:823:28)
    at ESLint.lintFiles (/home/iojs/workspace/sxa-rvnodetest/tools/node_modules/eslint/lib/eslint/eslint.js:551:23)
    at Object.execute (/home/iojs/workspace/sxa-rvnodetest/tools/node_modules/eslint/lib/cli.js:417:36)
    at async main (/home/iojs/workspace/sxa-rvnodetest/tools/node_modules/eslint/bin/eslint.js:135:24)
Running Markdown linter...

I'll leave the job running daily without --with-intl=none and see if any hangs show up now.

[mhdawson]

@richardlau Do you know if that is correct or if it can be considered "complete" with no-asm?

I think this mostly affects performance. I don't think it would necessarily be a blocker.

[github-actions]

This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.

[sxa]

@nodejs/build Revisiting this because it's been marked as stale (and we ran out of time in the call today for me to raise it). We describe experimental platforms as "May or may not pass test suites. The core team does no create releases for these platforms". Given that we have unofficial builds and there is generally a desire to fix those when they go wrong (but it doesn't pass all the test cases yet) are we in a position where we can consider riscv64 a valid "experimental tier" platform?
Related: nodejs/node#42251

[ilg-ul]

@sxa, @luyahan, I contacted Ludovic Henry from the Language Runtime WG in RISE and he would be happy to integrate a group maintaining node, if there is interest.

I don't know the team who worked on the RISC-V port, but I think they would also be a good candidate to be part of a RISC-V node WG.

Stewart, apparently you already contacted RISE, perhaps you can catalyse the efforts and reach some agreement with them.

[sxa]

Yep I know Ludovic and am involved with that working group (Not just for Node stuff) ;-)
I'm obviously happy to help out (I've got four RISC-V boards within arms reach here and obviously I set up the unofficial builds for it) but RISC-V is not my primary day job (unfortunately!) so I can't guarantee that I can look into any problems in a timely manner so ideally we'd have someone else in the community willing to stand up for that before we promote it. I can likely handle infra related stuff but the issue we have is "What if the build breaks due to a code issue?" which is generally the Node.js criteria for bumping it up.

[ilg-ul]

@sxa, could you contact me by email?

[sxa]

@sxa, could you contact me by email?

Done - to the address on your github profile. I'm also on the openjsf slack (and various others!) if you want to contact me there :-)

[mhdawson]

@sxa are the only RISC-V boards used for teesting currently the ones you have?

[sxa]

@sxa are the only RISC-V boards used for teesting currently the ones you have?

Yes. but only one (not one in my house!) is connected to the Node CI.

[targos]

I created the @nodejs/platform-riscv64 GitHub team and invited @sxa to it.
Anyone else who would like to be notified about RISC-V stuff?

[ilg-ul]

I'd like to be notified about RISC-V stuff.

[drom]

@targos please add me tot the list

[targos]

I invited both of you.

[targos]

@luyahan would you like to be part of the team?

[olof-nord]

I realise I am quite late to reply, but if possible I am also (still) interested to be notified about RISC-V stuff.

[targos]

@olof-nord you're invited too :)

[EwoutH]

Any updates on this effort? What's needed to move it forward?