Thanks for the contribution! I'd recommend adding a skeleton toolchain dir structure to clang/test/Driver/Inputs and adding a test to clang/test/Driver/riscv64-toolchain.c. You should be able to see examples in test/Driver/Inputs.
hexchain pointed me to this patch and asked why Suse can add a triple here... So here are some explanations:
We should avoid adding more target triples to CollectLibDirsAndTriples.
Every riscv64 user will waste some fstat or openat.
(If there are 100 distros customizing riscv64, apparently we shouldn't enumerate them.)
The list is mainly there so that clang --target=riscv64 can magically pick riscv64-linux-gnu (and other RISCV64Triples triples).
This behavior is really discouraged for newer architectures and OSes.
They should just specify the full triple clang --target=riscv64-suse-linux. This doesn't require you to add anything to the list.
If on riscv64-suse-linux, clang for some reason doesn't recognize riscv64-suse-linux.
The correct fix is to make LLVM_DEFAULT_TARGET_TRIPLE riscv64-suse-linux.
This doesn't need any hardcoded value from RISCV64Triples.
So why cannot we clean these RISCV64Triples?
Perhaps the reason is that some users are unfortunately relying on the behavior.
Deleting these values will be the correct way forward but they can be unhappy temporarily.