Fix multiple RISC‑V build issues: correct -march generation and improve LLD detection (CMake & Makefile)

[fengpengboa]

Description

This PR consolidates fixes for two independent but related build problems on RISC‑V:

• Broken native optimisation in build_detect_platform (typo + unsafe -march string)
• LLD linker detection false positives in both CMake and Makefile builds

All changes are now included in this single PR. The other two PRs will be closed.

Problem 1 – Dead code and broken -march on modern RISC‑V

Background

In build_tools/build_detect_platform, there is a section intended to optimize RocksDB for RISC-V natively by parsing /proc/cpuinfo to populate the -march flag.However, it contained a typo: it assigned the result to RISC_ISA but checked if [ -n "${RISCV_ISA}" ]. Due to this typo, the RISC-V specific hardware optimization was effectively dead code and never executed.If one simply fixes the typo (RISC_ISA -> RISCV_ISA), the build immediately breaks on modern RISC-V hardware due to a mismatch between bleeding-edge Linux kernels and the GNU toolchain.

Crash 1: GCC rejects privileged extensions
Modern RISC-V Linux kernels report Supervisor-level (_s*), Hypervisor-level (_h*), and Custom (_x*) extensions in /proc/cpuinfo (e.g., sscofpmf_sstc_svinval).
Passing this raw string to GCC when compiling user-space code like RocksDB causes a fatal error:

$DEBUG_LEVEL is 0, $LIB_MODE is static
g++: error: ‘-march=rv64imafdcv_zicbom_zicboz_zicntr_zicond_zicsr_zifencei_zihintntl_zihintpause_zihpm_zawrs_zfa_zfh_zfhmin_zca_zcb_zcd_zba_zbb_zbc_zbs_zve32f_zve32x_zve64d_zve64f_zve64x_zvfh_zvfhmin_sscofpmf_sstc_svinval_svnapot_svpbmt’: unexpected ISA string at end: ‘sscofpmf_sstc_svinval_svnapot_svpbmt’

Crash 2: Binutils (Assembler) truncates the ISA string and loses zbb/zbs
Even if we strip the privileged _s* extensions, the kernel also exposes newly ratified user-space extensions (like zicntr or zihpm). Older versions of Binutils (as) do not recognize these new zi* extensions.
When the assembler encounters an unknown extension like zicntr, it throws:

Assembler messages:
Error: rv64imafdcv_zicbom _zicboz_zicntr_zicond_zicsr_zifencei_zihintntl_zihintpause_zihpm_zawrs_zfa_zfh_zfhmin_zca_zcb_zcd_zba_zbb_zbc_zbs_zve32f_zve32x_zve64d_zve64f_zve64x_zvfh_zvfhmin_zvl128b_zvl32b_zvl64b: unknown prefixed ISA extension `zicntr'
/tmp/ccZR3Vg7.s:3: Error: rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_v1p0_zicbom_zicboz_zicntr_zicond_zicsr2p0_zifencei2p0_zihintntl_zihintpause_zihpm_zawrs_zfa_zfh_zfhmin_zca_zcb_zcd_zba1p0_zbb1p0_zbc1p0_zbs1p0_zve32f1p0_zve32x1p0_zve64d1p0_zve64f1p0_zve64x1p0_zvfh_zvfhmin_zvl128b1p0_zvl32b1p0_zvl64b1p0: unknown prefixed ISA extension `zicntr'
/tmp/ccZR3Vg7.s:1702: Error: unrecognized opcode `bseti a5,zero,63', extension `zbs' required
/tmp/ccZR3Vg7.s:1854: Error: unrecognized opcode `bseti a5,zero,63', extension `zbs' required

The Solution:

To make the build script robust against future kernel updates and lagging toolchains, this PR introduces:

1. Typo Fix: Corrected variable names to activate the logic.
2. Whitelist Filtering: Instead of passing everything, we extract the Base ISA (e.g., rv64imafdcv) and strictly append only safe, performance-enhancing extensions that RocksDB actually benefits from: _zb* (Bitmanip), _zv* (Vector), and _zk* (Crypto).
3. Feature Probing: Added a dummy C++ compilation probe (echo "int main(){}" | $CXX ...). Before trusting the synthesized -march string, we test if the local host compiler can actually parse it. If it fails (e.g., severely outdated GCC), it gracefully falls back to the compiler's default.

---

Problem 2 – LLD detection is too simple and breaks on RISC‑V (CMake + Makefile)

Background——CMake

Currently, CMake only checks if the lld executable exists and can output its version (execute_process(COMMAND ... -Wl,--version)). It does not verify if lld can actually link the object files generated by the current compiler.
On RISC-V architecture, modern GCC emits R_RISCV_SET_ULEB128 (60) and R_RISCV_SUB_ULEB128 (61) relocations in the .gcc_except_table section for C++ exception handling. Older versions of LLD do not support these ULEB128 relocations. Because the current CMake script blindly enables LLD without a feature test,the build fails midway with ld.lld: error: unknown relocation (60) against symbol

ld.lld: error: CMakeFiles/rocksdb-shared.dir/cache/cache_entry_roles.cc.o:(.gcc_except_table+0x3): unknown relocation (60) against symbol .LLSDACSE6132
ld.lld: error: CMakeFiles/rocksdb-shared.dir/cache/cache_entry_roles.cc.o:(.gcc_except_table+0x3): unknown relocation (61) against symbol .LLSDACSB6132
ld.lld: error: CMakeFiles/rocksdb-shared.dir/cache/cache_entry_roles.cc.o:(.gcc_except_table+0x4): unknown relocation (60) against symbol .LEHB0
ld.lld: error: CMakeFiles/rocksdb-shared.dir/cache/cache_helpers.cc.o:(.gcc_except_table+0x3): unknown relocation (60) against symbol .LLSDACSE8334

The Solution :

Replaced the simple version check with a robust feature test using CMake's CheckCXXSourceCompiles. I added a minimal test snippet containing a try-catch block. This forces the compiler to generate the .gcc_except_table. If LLD fails to link it, CMake gracefully falls back to the default compiler linker (e.g., GNU ld.bfd) instead of breaking the build.

Background——Makefile

This is the Makefile/script equivalent of the CMake fix for the LLD linker detection. It ensures that build_detect_platform does not falsely enable LLD on systems where it cannot link C++ exception tables (specifically on RISC-V with older LLD versions).The current script checks if LLD is usable by compiling a trivial program: int main() { return 0; }.
This check is too simple because it does not generate a .gcc_except_table section.
On RISC-V, modern compilers use R_RISCV_SET_ULEB128 relocations for C++ exceptions. Older LLD versions do not support these relocations. Because the trivial main() test passes successfully, the script adds -fuse-ld=lld to PLATFORM_LDFLAGS. Later, when compiling actual RocksDB code (which heavily uses exceptions), the build crashes with unknown relocation (60).

/usr/bin/ar: creating librocksdb.a
  CCLD     db_repl_stress
  CCLD     db_sanity_test
  CCLD     write_stress
  CCLD     rocksdb_dump
  CCLD     rocksdb_undump
ld.lld: error: ./librocksdb.a(cache_helpers.o):(.gcc_except_table+0x3): unknown relocation (60) against symbol .LLSDACSE8331
ld.lld: error: ./librocksdb.a(cache_helpers.o):(.gcc_except_table+0x3): unknown relocation (61) against symbol .LLSDACSB8331
ld.lld: error: ./librocksdb.a(cache_helpers.o):(.gcc_except_table+0x4): unknown relocation (60) against symbol .LEHB0

The Solution:

Updated the dummy C++ code in build_tools/build_detect_platform to include a try { throw 1; } catch (...) {} block.
This forces the compiler to generate the exception handling sections during the detection phase. If the installed LLD cannot link these sections, the test fails, and the script safely ignores LLD, falling back to the default GNU linker.

Test

Tested natively on a modern RISC-V (rv64) SG2044 environment

[meta-cla]

Hi @fengpengboa!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

[fengpengboa]

Hi @archang19 , I have a CLA-related question for this PR.Our company has previously signed the Meta Corporate CLA for other open source projects. When I tried to sign again for RocksDB, the system indicated that our company is already registered and prevented me from signing a new one.However, I do not know who the original signer was, and I am unable to locate that person internally to be added to the authorized contributor list.
I have already sent an email to cla@meta.com regarding this, but haven't received a response yet. Could someone please help check the status or assist in associating my GitHub account with our company's existing CLA record?Thank you for your help!

[xingbowang]

Could you close multiple PRs, and just have one PR for fixing build issue on RISC-V?

[fengpengboa]

Could you close multiple PRs, and just have one PR for fixing build issue on RISC-V?

Sure, will close the other two PRs and put everything into this one. Thanks for the suggestion!

[fengpengboa]

@xingbowang, I have merged the RISC-V build/compilation PR into this one. Could you please review when you get a chance? Thanks.