From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) by mx.groups.io with SMTP id smtpd.web10.1963.1671243367379650180 for ; Fri, 16 Dec 2022 18:16:07 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@ventanamicro.com header.s=google header.b=PNFEByLQ; spf=pass (domain: ventanamicro.com, ip: 209.85.208.46, mailfrom: tphan@ventanamicro.com) Received: by mail-ed1-f46.google.com with SMTP id c66so6008596edf.5 for ; Fri, 16 Dec 2022 18:16:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=E7ZlZrpPxUguN0veyDK9kJAUArsIP5FeKKnts9mEhwc=; b=PNFEByLQQmTaRlQVrZdXkd0QrNMKmzcHpKt2ujgWrakIMFPvtXHhsIcrzlddbtvRz6 MJ7w52Gy1jq1FzYaoSl6K/pKayOTzfQzQHr2BY4IdNsC3WOAK5KLSl5Fo5Ea6O6Npnkb BwQn6ObdM53U9S9miX4y3QqKLPjAU2Ll/mTdVhICq8VCV4R+WT0acX7f8iUFavwcktvq EVKR9QI8jtIPIVfoMZMQfnDCO1Zu18uKHqIkKmr+SUCqWoYJUJjcOWF31hh6fE2W5klr NB2jeUZ2W7tUVFHpmJF2LtI6FI08/h28jRUBvIVHyG8np0H9u2NmfqjbNCr7o/dmA/Pf UCHw== 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=E7ZlZrpPxUguN0veyDK9kJAUArsIP5FeKKnts9mEhwc=; b=oNjvzU2gKyKI7/QyBquEcLUiDCw0urkkKZ/+iBY84H/Fp7/5EdAqAunRJKcc7RRGOv PKD7Lu5Tr323oQMK7xr/ZXE34ktUibrBc1J5XnPGpW5ddXTFa/kCfDtehymAviZeYuKH tjTL06i9svd0lNivtMgor7FTb+Y8LjIXMhjk8utfppcO4/ozhBqJW/vc++zfurvOYzrx gq9DC/f3NC0M00HAfy+AnufYkW0tasAmkwvwUfRJZVvvUYLlW9+tp9jcbZReicUvWWmE jcGQ/kYQqn/mRfUJ0dqa4A6k9E4vjOQel2wlOl9iHnR4GyP+d5Oi48M3k1WWpwDAz5uG AZzw== X-Gm-Message-State: ANoB5pk6vw8VLxZ58uuUU2sMx0NWdMMrKD3nouo0P5J93JsITigVJvgD SR5E6jdOrmtvDAvn6JJaS5NBGolkjgdETUkaPR42QQ== X-Google-Smtp-Source: AA0mqf6LGQRi5fHkczlEPmEDYETLwLFj6HWI774PwDHBaJf4MThYTEMHMSzftCqeBZZpEq2vVpR1BXydtOjddJevjPk= X-Received: by 2002:aa7:d44d:0:b0:46d:7d3c:30cc with SMTP id q13-20020aa7d44d000000b0046d7d3c30ccmr6344673edr.322.1671243365886; Fri, 16 Dec 2022 18:16:05 -0800 (PST) MIME-Version: 1.0 References: <20221216184754.4381-1-tphan@ventanamicro.com> In-Reply-To: From: "Tuan Phan" Date: Fri, 16 Dec 2022 18:15:54 -0800 Message-ID: Subject: Re: [edk2-devel] [PATCH v2] CryptoPkg/IntrinsicLib: RiscV: Provide implementation of memcpy and __ctzdi2 To: Pedro Falcato 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="00000000000028441c05effcab5e" --00000000000028441c05effcab5e Content-Type: text/plain; charset="UTF-8" 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. Tuan > Pedro > --00000000000028441c05effcab5e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
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 Mich= ael D Kinney <michael.d.kinney@intel.com> wrote:
If that intrinsic is= specific to RISCV, then should CompilerHelper.c go into a RiscV64 subdir?<= /blockquote>

Mike and Tuan,

Two= comments:
1) __ctzdi2 is not riscv specific and is a part o= f 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 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.

Tuan
Pedro
--00000000000028441c05effcab5e--