doc: fix riscv64 info in platform list

[RevySR]

No description provided.

[nodejs-github-bot]

Review requested:

• @nodejs/build
• @nodejs/tsc

[RevySR]

#42251 (comment)

[sxa]

I guess it depends on which levels we want to include in here. The unofficial builds are building with a later glibc than the ones in this PR so we'd have to be careful to ensure that the project does not mislead people (or not notice when the required level increased). Having said that, I'm also not certain how these were determined. I suspect most versions of node could still build with earlier ones than those listed in this doc.

Some of the earlier unofficial-builds on this platform were built against an older glibc as I recall but that was moved up when the cross-compiler environment was updated last year.

[RevySR]

I guess it depends on which levels we want to include in here. The unofficial builds are building with a later glibc than the ones in this PR so we'd have to be careful to ensure that the project does not mislead people (or not notice when the required level increased). Having said that, I'm also not certain how these were determined. I suspect most versions of node could still build with earlier ones than those listed in this doc.

Some of the earlier unofficial-builds on this platform were built against an older glibc as I recall but that was moved up when the cross-compiler environment was updated last year.

kernel >= 5.19, glibc >= 2.36

This value is loong64, the version that first appeared in the Linux kernel and glibc, but riscv64 is not.
RV64 first appeared in the linux kernel in 4.15, and first appeared in glibc in 2.27.

[sxa]

This value is loong64, the version that first appeared in the Linux kernel and glibc, but riscv64 is not. RV64 first appeared in the linux kernel in 4.15, and first appeared in glibc in 2.27.

Yep understood (I had a Beagle-V beta RISC-V board with the version of Fedora with that glibc). However for other architectures we list glibc2.28 and that's not just because the platform support was added in those versions - it's what we have built on and so we know that it works. Having said that as an unofficial platform if it can still be confirmed that node will build against 2.27 I'd probably be ok with stating that level in here.

[sxa]

Have tested a build of v24.13.1 with the Adoptium devkit which uses GCC14.2 and it failed to find __NR_riscv_flush_icache which is used by V8 (referenced in

node/deps/v8/src/codegen/riscv/cpu-riscv.cc

Line 23 in 9cc7fcc

syscall(__NR_riscv_flush_icache, start, end, 0);

) so I don'r think it's appropriate to say that node can be built with that version on riscv64.

../deps/v8/src/codegen/riscv/cpu-riscv.cc: In static member function 'static void v8::internal::CpuFeatures::FlushICache(void*, size_t)':
../deps/v8/src/codegen/riscv/cpu-riscv.cc:23:11: error: '__NR_riscv_flush_icache' was not declared in this scope
   23 |   syscall(__NR_riscv_flush_icache, start, end, 0);
      |           ^~~~~~~~~~~~~~~~~~~~~~~
make[1]: *** [tools/v8_gypfiles/v8_base_without_compiler.target.mk:1134: /home/sxa/node/out/Release/obj.target/v8_base_without_compiler/deps/v8/src/codegen/riscv/cpu-riscv.o] Error 1
make[1]: *** Waiting for unfinished jobs....

From looking at the glibc source it looks like that symbol was added in glibc 2.31, but without additional testing I'd be against modifying this document to state that it works with that version, but it means that the head build will definitely NOT build against glibc 2.27 without additional patching.

[RevySR]

From looking at the glibc source it looks like that symbol was added in glibc 2.31, but without additional testing I'd be against modifying this document to state that it works with that version, but it means that the head build will definitely NOT build against glibc 2.27 without additional patching.

The problem is that previous versions were completely unproven and copied from loong64, which is definitely unacceptable.

[RevySR]

__NR_riscv_flush_icache

node/deps/v8/src/codegen/arm64/cpu-arm64.cc

Lines 55 to 59 in 9cc7fcc

	#elif defined(V8_OS_LINUX)
	char* begin = reinterpret_cast<char*>(address);
	__builtin___clear_cache(begin, begin + length);
	#else

This can be modified to be the same as arm64.

cc @kxxt