On Fri, Dec 16, 2022 at 5:59 PM Pedro Falcato <pedro.falcato@gmail.com>
wrote:

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

Tuan

> Pedro
>