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
