On Tue, 31 Mar 2020 at 16:36, Kinney, Michael D <michael.d.kin...@intel.com> wrote: > > ARM and AARCH64 have a compiler intrinsic lib that is linked against all > modules. > > [LibraryClasses.ARM, LibraryClasses.AARCH64] > # > # It is not possible to prevent ARM compiler calls to generic intrinsic > functions. > # This library provides the instrinsic functions generated by a given > compiler. > # [LibraryClasses.ARM] and NULL mean link this library into all ARM images. > # > NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf > > Can we use this same technique for IA32/X64 VS builds? >
In my opinion, having these intrinsics libraries added via NULL library class resolution was a mistake to begin with. Every component that we build incorporates some kind of startup code library that defines the _ModuleEntryPoint symbol, and it would be much better to make those libraries include an IntrinsicsLibrary dependency that can be satisfied by arch specific versions that also encapsulate the toolchain dependencies (such as this _fltused symbol, or memcpy/memset on ARM/GCC). On another note, it is still deeply disappointing that we need to jump through all of these hoops because the *only* single use of floating point in OpenSSL is the entropy estimate of an RNG, which is in the range of 0..1023 to begin with [IIRC). Remember that we also have a softfloat submodule for 32-bit ARM, for the same stupid reason. If we could stop pulling in that part of the code (or replace it with an UINT16 when building for the UEFI target), the whole floating point issue would mostly go away AFAICT. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#56817): https://edk2.groups.io/g/devel/message/56817 Mute This Topic: https://groups.io/mt/72648022/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
