From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f180.google.com (mail-pg1-f180.google.com [209.85.215.180]) by mx.groups.io with SMTP id smtpd.web11.9964.1671591416583315826 for ; Tue, 20 Dec 2022 18:56:56 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20210112 header.b=l81VhGkC; spf=pass (domain: gmail.com, ip: 209.85.215.180, mailfrom: pedro.falcato@gmail.com) Received: by mail-pg1-f180.google.com with SMTP id 79so9550087pgf.11 for ; Tue, 20 Dec 2022 18:56:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=MOwVkS1KEC4kSga4jEoZGFDEntAWeLcmnjlq77mKjno=; b=l81VhGkCl6IRV7cjy3BaJBXcsWLJgd3qsrH49EAo6cNG5CFFWTavqY7jESwf4ZPyJ7 GndimNnAfpALiQcuvNhAGBsndAJTsULo35sZam7gPSQFFmy5wPmT555npBwls4QersNT P4/btuv/If76bYH8F9axyWqwjqRAicLPx+dmphhKRP0hQSbug4CPDNfAEGH9NfWWo4Bb AfpuKEORe/L6TCGPxjO621Nw/C8YjYMWDL3hoLvX/iO9R58hZ+MWsA+YGU55UrOlKhoy dLc5R06r8byYhKUn56K9IArFMcb7yYPi10rOZHRI1PWul8Eglk+eCajBHQ5Xic/xeGxd LgYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=MOwVkS1KEC4kSga4jEoZGFDEntAWeLcmnjlq77mKjno=; b=jCwUI7CTBxxY0bYVEwqFLIoGDZH5Sn5FXQ1rYPSxFmV0B8UTYaGpADyJOdCDlsPWs6 2Yg/JT6WZrO0KX2RCztEIbp4asMrPV5szreN81HN30gGy1wRraHDDi83b4ggvooOATlL +VZAmCs8A6lDouBR5ZX8pHNTuzujOqJxzjtf3NOUJr2YQbuLCPhp8x1QrCYzoVH9NuPl 7VSoTXwzHeSQvjIFxt87InmDYiWQd2u7BFX+FvH5sDKjPEpxdKhwabWL17wbBWRaW/lY mCHxUIDjZimGQsuKZ7uc9qQe1QyamBD7Md7I0V0EWZXsFNXYR22HZep0he3bfEG9HdBU XBCQ== X-Gm-Message-State: ANoB5pnDi+qlTH5eLJJi6P+mGxPyY2ZqLr0CvX8A1GCx1nEQxsRCX3Wv FtbyTFvp5KYoIWAtcLv1uGZUDod33bDezN7JgXA= X-Google-Smtp-Source: AA0mqf56nyiihgXejOcvK31eK5p9bNJpVPTEKYZVsvEgTfRHemYM5flBusHmXC6beHUMKZ+M1vPyjKKYue2xG15sCfI= X-Received: by 2002:a63:5409:0:b0:476:e3bb:2340 with SMTP id i9-20020a635409000000b00476e3bb2340mr69952765pgb.530.1671591415788; Tue, 20 Dec 2022 18:56:55 -0800 (PST) MIME-Version: 1.0 References: <20221216184754.4381-1-tphan@ventanamicro.com> In-Reply-To: From: "Pedro Falcato" Date: Wed, 21 Dec 2022 02:56:44 +0000 Message-ID: Subject: Re: [edk2-devel] [PATCH v2] CryptoPkg/IntrinsicLib: RiscV: Provide implementation of memcpy and __ctzdi2 To: Tuan Phan Cc: devel@edk2.groups.io, michael.d.kinney@intel.com, "sunilvl@ventanamicro.com" , "Yao, Jiewen" , "Wang, Jian J" , "Lu, Xiaoyu1" , "Jiang, Guomin" Content-Type: multipart/alternative; boundary="0000000000008c3b8005f04db492" --0000000000008c3b8005f04db492 Content-Type: text/plain; charset="UTF-8" On Sat, Dec 17, 2022 at 2:16 AM Tuan Phan wrote: > > > On Fri, Dec 16, 2022 at 5:59 PM Pedro Falcato > 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 --0000000000008c3b8005f04db492 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Dec 17, 2022 at 2:16 AM Tuan Phan= <tphan@ventanamicro.com&g= t; 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 Compiler= Helper.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 lib= gcc/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 me= mcpy (see htt= ps://godbolt.org/z/xYsYEq6En for an example). In fact, fno-builtin-memc= py will call memcpy more,
as GCC stops assuming normal behavior f= rom memcpy and generates calls instead of e.g inlining memcpy code.
GCC and clang require memcpy, memmove, memset and memcmp (with stand= ard C library behavior) to compile code. AFAIK no option can change this.
GCC and clang also require libgcc/compiler-rt (although getting ar= ound this is saner and way more reliable, done in e.g operating system kern= els such as linux itself).

The only way = to reliably generate code with GCC/clang is to have the CompilerIntrinsicsL= ib 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.c= om/heatd/edk2/commits/toolchain-fixes). Can we properly fix this?

It would not be a problem if lib= gcc/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 wit= h BaseTools.
We can't link with the = standard libgcc/compiler-rt that comes with the toolchain due to various re= asons:
1) Your toolchain may not even have one (most clang toolch= ains out there support cross-compilation to RISCV but don't come with p= re-compiled runtimes due to size constraints)
2) Your architectur= e may need to pass special compile options for safe usage of runtime librar= ies (like x86_64's -mno-red-zone on SysV ABI)
3) Your archite= cture may straight up refuse to link with object files compiled in other mo= des - this is the case in RISCV, as e.g you can't link softfloat with h= ardfloat object files

So we need to carry a libgcc= in EDK2. I know there have been efforts in the past to consolidate all the= se little compiler intrinsic implementations into a specific spot, I don= 9;t know what came of that.
But we definitely should make BaseToo= ls enforce compiler runtime libs when building - it's the only safe and= backwards compatible choice, and if we add more runtime libraries (think U= BSAN or ASAN) those can be silently added to BaseTools as well.
<= br>

Pedro
--0000000000008c3b8005f04db492--