On Sat, Dec 17, 2022 at 2:16 AM Tuan Phan <tp...@ventanamicro.com> wrote:
> > > On Fri, Dec 16, 2022 at 5:59 PM Pedro Falcato <pedro.falc...@gmail.com> > wrote: > >> On Sat, Dec 17, 2022 at 12:06 AM Michael D Kinney < >> michael.d.kin...@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 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#97650): https://edk2.groups.io/g/devel/message/97650 Mute This Topic: https://groups.io/mt/95721978/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
