Scott, Thank you for reporting this. I have added it to the list of issues to be resolved for StdLib.
Regrettably, I haven't done any testing with VS2013. While one is free to use the SSEx and MMX registers and instructions in their own code, it isn't a supported feature of EDK II. A compilation unit using these extensions must confine all artifacts of such use within the compilation unit. No assumptions may be made about external code's use, preservation, or destruction of these registers. Within a compilation unit, one is free to use any calling convention supported by the target compilers, as long as all public APIs use the EFIAPI calling convention, which does not address these registers. Regarding your questions: 1) I don't know about combining modules compiled with /arch:SSE2 and /arch:SSE. My assumption has been that both of these have been "turned off" since we didn't want the compiler generating these instructions. It looks like I need to do some more research in this area. 2) The ftol2.obj binary is compatible with VS2003 through VS2012. I don't yet know about VS2013. Daryl McDaniel "It is the mark of an educated mind to be able to entertain a thought without accepting it." - Aristotle -----Original Message----- From: Scott Duplichan [mailto:sc...@notabs.org] Sent: Thursday, September 04, 2014 9:41 PM To: edk2-devel@lists.sourceforge.net Subject: [edk2] VS2013 build failures: unresolved external symbol __dtoui3 Building AppPkg for IA32 using VS2013 fails with unresolved external symbol __dtoui3. __dtoui3 is a helper function called by the generated code. It is analogous to the __ftol2 helper function call generated by older Microsoft compilers. VS2013 calls __dtoui3 instead of __ftol2. Apparently the new function converts double to integer with reduced use of the x87 fpu. The call to __ftol2 generated by older Microsoft compilers is resolved by binary file StdLib\LibC\Main\Ia32\ftol2.obj, an object extracted from Microsoft libs. The same approach could be used for VS2013's __dtoui3 by extracting ftol3.obj and adding it to EDK2. But doing so causes unresolved external symbol __except1. This can be fixed by extracting fpexcept.obj from VS2013 libs and adding it to EDK2. But once that is done, 12 more unresolved externals are created. Another approach is to use /arch:SSE when building LibGdtoa for IA32 with VS2013 (default is /arch:SSE2). This causes VS2013 to generate a call to __ftol2 instead of __dtoui3 and resolves the build failure. I suppose this is the route to take. Concerns are: 1) Is it OK to combine modules compiled with /arch:SSE2 and /arch:SSE? 2) Is the current EDK2 ftol2.obj binary compatible with all supported Microsoft compilers, including VS2013? I will do some testing and submit a patch if it looks OK. Thanks, Scott ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
