On Sat, Dec 17, 2022 at 12:06 AM Michael D Kinney <
michael.d.kinney@intel.com> wrote:

> 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).

I actually ran into this issue a few weeks back when trying to add security
features (https://github.com/heatd/edk2/commits/toolchain-fixes). Can we
properly fix this?

Pedro