Re: [edk2-devel] [PATCH v2] CryptoPkg/IntrinsicLib: RiscV: Provide implementation of memcpy and __ctzdi2

["Pedro Falcato" <pedro.falcato@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3110 bytes --]

On Sat, Dec 17, 2022 at 2:16 AM Tuan Phan <tphan@ventanamicro.com> wrote:

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

[-- Attachment #2: Type: text/html, Size: 4490 bytes --]