> -----Original Message----- > From: Ard Biesheuvel <a...@kernel.org> > Sent: Friday, August 2, 2024 1:46 AM > To: Oliver Smith-Denny <o...@linux.microsoft.com> > Cc: devel@edk2.groups.io; Leif Lindholm <quic_llind...@quicinc.com>; Sami > Mujawar <sami.muja...@arm.com>; Kinney, Michael D > <michael.d.kin...@intel.com>; Liming Gao <gaolim...@byosoft.com.cn>; Liu, > Zhiguang <zhiguang....@intel.com> > Subject: Re: [RFC] Move CompilerIntrinsicsLib and ArmSoftFloatLib to MdePkg > > On Fri, 2 Aug 2024 at 00:39, Oliver Smith-Denny > <o...@linux.microsoft.com> wrote: > > > > CompilerIntrinsicsLib and ArmSoftFloatLib add ARM/AARCH64 compiler > > intrinsics and floating point functions required by OpenSSL, > > respectively. CompilerIntrinsicsLib is used almost in every DSC that > > builds ARM/AARCH64 and ArmSoftFloatLib is used by every DSC that builds > > logic from OpenSSL. > > What's even worse: OpenSSL doesn't really use floating point at all - > the only reason we need this is because there is some global double_t > somewhere that records entropy or somesuch, but IIRC that code is not > actually used. > > So perhaps we could add a hack in OpensslLib to work around this in > one way or another for ARM only, and get rid of SoftFloatLib > altogether. > > > Together these make almost every DSC have a > > dependency on ArmPkg, which is odd and for a handful, MdeModulePkg, > > EmbeddedPkg, and ShellPkg, namely, it is a circular dependency. > > > > There have been previous mailing list suggestions to move > > CompilerIntrinsicsLib to MdePkg (possibly combining with other arch > > intrinsics). I am not sure the end status of those conversations. By > > moving these two libraries to MdePkg package, we accomplish a few > > things: > > > > - Removing the circular dependency from MdeModulePkg and ShellPkg > > (EmbeddedPkg has other ArmPkg dependencies) > > > > - Aligning MdePkg as the base package where baseline build and spec > > dependencies are found with other industry standard behavior > > > > - Detangling ArmPkg and making ARM/AARCH64 more of a first class > > citizen in edk2 instead of bolted onto the side > > > > There is no functional change here and the amount of work is light, but > > I think it moves edk2 in the direction it wants to go, so I'm happy to > > put up a PR for this, but I wanted to get feedback before I did so. This > > aligns with similar efforts, such as moving more ARM/AARCH64 chipset > > definitions to MdePkg from ArmPkg [1][2][3]. This also aligns to the > > overall goal of deleting ArmPkg: > > https://bugzilla.tianocore.org/show_bug.cgi?id=4121 > > > > Intrinsics are tightly coupled with the toolchain, and so it would > make sense for the basetools to provide them. Intrinsics are also > -essentially- build once, run everywhere objects so I don't think we > need the typical handling for them either, and we could just build > them once when we build the basetools.
I do not think this is possible * BaseTools are built with the host compiler. * FW is built with the target compiler which may be different than the host compiler. And multiple target compilers or target compiler CPU target may be used from a single host build environment. An intrinsic lib instance is needed for each unique target used. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#120212): https://edk2.groups.io/g/devel/message/120212 Mute This Topic: https://groups.io/mt/107675828/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
