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

Reply via email to