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?