From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51]) by mx.groups.io with SMTP id smtpd.web10.1683.1671242381642630737 for ; Fri, 16 Dec 2022 17:59:41 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20210112 header.b=pN4KDXYG; spf=pass (domain: gmail.com, ip: 209.85.216.51, mailfrom: pedro.falcato@gmail.com) Received: by mail-pj1-f51.google.com with SMTP id b13-20020a17090a5a0d00b0021906102d05so4045089pjd.5 for ; Fri, 16 Dec 2022 17:59:41 -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=JhpMpLrnDHi7xoGXr4BZrUAOE5e0Wm/RJobV0IuVXKc=; b=pN4KDXYGIc6A7fulzGJ714jngleNAqONaEP0aauBVNdchuvSFAfHc+zu6r6L1xmt4P hGiKnPZZRmFxUczCKVPO73ZyKWUsbBhLRf79wxzCUVDkzxX0EEt8P+DQYRBFMYVkAklS 5frfi1o6I8EIIbpDzvRh+aSmag7uHlv7p3UUguDj/34G8mvzEA3gjr+W1st7lq6/1GM/ x09IeuuCVzIQ8vLPY9/WUzjPGT5zCwSbkm3UIX3Dzg0ZvfcsQEFMFIo3KhmvdvuGFIdO XiyeMy7ObnVwmA5Fb+vbbWqi1eaXY7q3rDRftyuWsjqXrR01LD6BYl+4uFBFGRYvvJ9Y iJxA== 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=JhpMpLrnDHi7xoGXr4BZrUAOE5e0Wm/RJobV0IuVXKc=; b=WHqcF+pMBqd8TTZrHKTbjOkSmviG2wr0JMFN3U2TIx9PbpsVs9Hz6yZXn51UGtKIkJ 3uTRGKqeQlYOrIMSqKdto1+leTEbAWkffWbHZFh0Vk+CSQuDBieApZo72AEqnkG3GrJb ETLRUT8GklA2dgYQuxB56YD3QA/GuSA216odRaBY3OndD0qkurAa2IRc6mrKh/3pLl8b CmAogiQg+ekyHmkVuiAIp/OprJ2iHITdQNSepBwti50bWwK3PgVE+BDedQpvHGcwBNvX RU8qaJwB4/TWOyJm5QMSGbkx40LRR+73OY4hqlpmtjCYU8wGo0t0sfawW/yRD0aPDksN wBsQ== X-Gm-Message-State: AFqh2kop4zEhubft1Pt3Czmz0/Yr5VmGyJCTK/jNsfoz2DzS9/dqxp6o 3PMxC8zzb1D+5yinOjZWkV7UhlWEE2CFGWEDq1AVHCZ6e/KSlkeZ X-Google-Smtp-Source: AMrXdXuc+o20IIv+2OTQvHBpZL8WjWweebg/iaj2DvOt9q0Ps2sF+oQi9WnW+Z83GelJ/EW6jIwymi5wb0Bu1gUEWCY= X-Received: by 2002:a17:902:fe0c:b0:190:e6eb:d54 with SMTP id g12-20020a170902fe0c00b00190e6eb0d54mr1094905plj.25.1671242380729; Fri, 16 Dec 2022 17:59:40 -0800 (PST) MIME-Version: 1.0 References: <20221216184754.4381-1-tphan@ventanamicro.com> In-Reply-To: From: "Pedro Falcato" Date: Sat, 17 Dec 2022 01:59:29 +0000 Message-ID: Subject: Re: [edk2-devel] [PATCH v2] CryptoPkg/IntrinsicLib: RiscV: Provide implementation of memcpy and __ctzdi2 To: devel@edk2.groups.io, michael.d.kinney@intel.com Cc: Tuan Phan , "sunilvl@ventanamicro.com" , "Yao, Jiewen" , "Wang, Jian J" , "Lu, Xiaoyu1" , "Jiang, Guomin" Content-Type: multipart/alternative; boundary="0000000000006fe52205effc70c5" --0000000000006fe52205effc70c5 Content-Type: text/plain; charset="UTF-8" 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 --0000000000006fe52205effc70c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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, th= en should CompilerHelper.c go into a RiscV64 subdir?

<= /div>
Mike and Tuan,

Two comments:
<= div>1) __ctzdi2 is not riscv specific and is a part of the standard functio= ns provided by libgcc/compiler-rt (read: the compiler can call it as it ple= ases)

> 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 https://godbolt.org/z= /xYsYEq6En for an example). In fact, fno-builtin-memcpy will call memcp= y more,
as GCC stops assuming normal behavior from memcpy and gen= erates calls instead of e.g inlining memcpy code.
GCC and cla= ng require memcpy, memmove, memset and memcmp (with standard C library beha= vior) to compile code. AFAIK no option can change this.
GCC and c= lang 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 genera= te 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 t= rying to add security features (https://github.com/heatd/edk2/commits/toolchain-fixe= s). Can we properly fix this?

Pedro
--0000000000006fe52205effc70c5--