If that intrinsic is specific to RISCV, then should CompilerHelper.c go into a RiscV64 subdir?
Mike and Tuan,
Two comments:
1) __ctzdi2 is not riscv specific and is a part of the standard functions provided by libgcc/compiler-rt (read: the compiler can call it as it pleases)
> Forcing to use CopyMem of EDK2 as memcpy buildin disabled for RiscV
> with -fno-builtin-memcpy flag.
2) Using -fno-builtin-memcpy doesn't stop GCC/clang from trying to call memcpy (see
https://godbolt.org/z/xYsYEq6En for an example). In fact, fno-builtin-memcpy will call memcpy more,
as GCC stops assuming normal behavior from memcpy and generates calls instead of e.g inlining memcpy code.
GCC and clang require memcpy, memmove, memset and memcmp (with standard C library behavior) to compile code. AFAIK no option can change this.
GCC and clang also require libgcc/compiler-rt (although getting around this is saner and way more reliable, done in e.g operating system kernels such as linux itself).
The only way to reliably generate code with GCC/clang is to have the CompilerIntrinsicsLib as a dependency for every platform compiled with GCC (or have BaseTools inject that).
It would not be a problem if libgcc/compiler-rt can be linked during the build process. With the -nostdlib flag enforced for most targets, each module needs to explicitly link libgcc in INF if want to use the compiler-rt functions. I am not sure what is the best way to do it unless we remove -nostdlib or enforce linking libgcc with BaseTools.
We can't link with the standard libgcc/compiler-rt that comes with the toolchain due to various reasons:
1) Your toolchain may not even have one (most clang toolchains out there support cross-compilation to RISCV but don't come with pre-compiled runtimes due to size constraints)
2) Your architecture may need to pass special compile options for safe usage of runtime libraries (like x86_64's -mno-red-zone on SysV ABI)
3) Your architecture may straight up refuse to link with object files compiled in other modes - this is the case in RISCV, as e.g you can't link softfloat with hardfloat object files
So we need to carry a libgcc in EDK2. I know there have been efforts in the past to consolidate all these little compiler intrinsic implementations into a specific spot, I don't know what came of that.
But we definitely should make BaseTools enforce compiler runtime libs when building - it's the only safe and backwards compatible choice, and if we add more runtime libraries (think UBSAN or ASAN) those can be silently added to BaseTools as well.
Pedro