Mike, As mentioned in previous mails, we can't change some of our code to meet the coding standard. I've filled BZ #1516 with everything we need, plus what CryptoPkg provides for reference.
Thanks, Richard. On Wed, 2019-01-30 at 20:58 +0000, Kinney, Michael D wrote: > Hi Richard, > > It is possible to update C code to prevent the use of compiler > intrinsic functions. This is what we have done for EDK II modules > that are built for both IA32 and X64. > > The one exception is the use of OpenSSL. We prefer to use that > project "as is" as a git submodule, so modifying the OpenSSL > sources to prevent use of intrinsic functions was not practical. > The CryptoPkg has the minimum set of intrinsic functions required > For OpenSSL to build. > > We do recognize that this issue is difficult for developers to > resolve because the techniques require generation of mixed C/asm > output files to track down the C statements that are generating > the intrinsic functions. > > Similar to the ARM support for an intrinsic lib, it may be > reasonable to add a small intrinsic lib for IA32 and X64 that > supports the intrinsic functions that are seen the most often. > May require an intrinsic lib for each supported tool chain. > > This would be a new feature that would take some effort to > implement and validate. Can you enter an Bugzilla for this > feature and list the specific intrinsic functions needed for > this driver? > > Thanks, > > Mike > > > -----Original Message----- > > From: Ryszard Knop > > [mailto:ryszard.k...@linux.intel.com] > > Sent: Wednesday, January 30, 2019 9:27 AM > > To: Ard Biesheuvel <ard.biesheu...@linaro.org>; edk2- > > de...@lists.01.org; Carsey, Jaben > > <jaben.car...@intel.com> > > Cc: Kacperski, Kamil <kamil.kacper...@intel.com>; Jin, > > Eric <eric....@intel.com>; Orlowski, Pawel > > <pawel.orlow...@intel.com>; Kinney, Michael D > > <michael.d.kin...@intel.com>; Hsiung, Harry L > > <harry.l.hsi...@intel.com> > > Subject: Re: [edk2] [PATCH edk2-staging 10/20] > > IntelUndiPkg/XGigUndiDxe: drop StdLibC library class > > reference > > > > That's actually not quite correct - we need this > > package to build on > > IA32. It's named rather unfortunately, since it's not > > the EDK2 StdLibC, > > but rather a package in this repository - see > > IntelUndiPkg/LibC. It > > contains the bare minimum of functionality required to > > fix missing 64- > > bit math/shifts on IA32 and missing memcpy/memset > > intrinsics. We can't > > prevent MSVC from yielding memcpy/memset either, so > > this was the nasty > > solution for build issues. You have included > > CompilerIntrinsicsLib for > > the same reason, too :) > > > > I'm not aware of any X64/IA32 equivalent of your > > CompilerIntrinsicsLib, > > but I'd be happy to be proven wrong here. I'm off for > > the rest of the > > week - I'll continue with reviews and merging early > > next week. > > > > Thanks, Richard. > > > > On Wed, 2018-11-14 at 18:33 -0800, ard.biesheuvela > > wrote: > > > StdLibc should not be used in drivers (it has > > dependencies on Shell > > > protocols), but in fact, we don't appear to rely on > > it in the first > > > place, so just drop the reference. > > > > > > Contributed-under: TianoCore Contribution Agreement > > 1.1 > > > Signed-off-by: Ard Biesheuvel <ard.biesheuvel at > > linaro.org> > > > --- > > > IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf | 1 - > > > 1 file changed, 1 deletion(-) > > > > > > diff --git a/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf > > > b/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf > > > index beee8aa8134e..b5747565fbea 100644 > > > --- a/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf > > > +++ b/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf > > > @@ -132,7 +132,6 @@ GCC:*_*_*_CC_FLAGS = -DEFI32 > > > PrintLib > > > UefiLib > > > HiiLib > > > - StdLibC > > > > > > [LibraryClasses.X64] > > > _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
