Here is a patch that fixes the VS2013-IA32 AppPkg build failure. It is
tested using 32-bit Duet to boot a shell and then run Enquire.efi. The
Enquire output (attached) matches that of the X64 build, except for
the expected data size differences.
--
StdLib: Fix VS2013-IA32 link failure caused by a compiler generated call to
__dtoui3. Changing the default VS2013 IA32 code
generation option from the default of /arch:SSE2 to /arch:SSE causes the
compiler to behave like previous editions and generate a
call to __ftol2 instead of __dtoui3.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Scott Duplichan <sc...@notabs.org>
Index: StdLib/LibC/gdtoa/gdtoa.inf
===================================================================
--- StdLib/LibC/gdtoa/gdtoa.inf (revision 16056)
+++ StdLib/LibC/gdtoa/gdtoa.inf (working copy)
@@ -76,3 +76,7 @@
LibLocale
LibStdLib
LibString
+
+[BuildOptions]
+ MSFT:*_VS2013x86_IA32_CC_FLAGS = /arch:SSE
+ MSFT:*_VS2013_IA32_CC_FLAGS = /arch:SSE
--
Thanks,
Scott
-----Original Message-----
From: Mcdaniel, Daryl [mailto:daryl.mcdan...@intel.com]
Sent: Friday, September 05, 2014 01:41 PM
To: edk2-devel@lists.sourceforge.net
Cc: Scott Duplichan
Subject: RE: [edk2] VS2013 build failures: unresolved external symbol __dtoui3
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
FS1:\> Enquire.efi
InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B F49BAA8
Loading driver at 0x0000F683000 EntryPoint=0x0000F687960
InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF F434710
InstallProtocolInterface: 752F3136-4E16-4FDC-A22A-E5F46812F4CA FE9DD0C
Produced by enquire version 5.1a, CWI, Amsterdam
http://www.cwi.nl/~steven/enquire.html
Compiler claims to be ANSI C level 1
Compiler names are at least 64 chars long
Preprocessor names are at least 64 long
SIZES
char = 8 bits, signed
short=16 int=32 long=32 float=32 double=64 bits
char*=32 bits
int* =32 bits
func*=32 bits
Type size_t is unsigned int/long
ALIGNMENTS
char=1 short=2 int=4 long=4
float=4 double=8
char*=4 int*=4 func*=4
CHARACTER ORDER
short: BA
int: DCBA
long: DCBA
PROPERTIES OF POINTERS
Char and int pointer formats seem identical
Char and function pointer formats seem identical
Strings are shared
Type ptrdiff_t is signed int/long
PROPERTIES OF INTEGRAL TYPES
Overflow of a short does not generate a trap
Maximum short = 32767 (= 2**15-1)
Minimum short = -32768
Overflow of an int does not generate a trap
Maximum int = 2147483647 (= 2**31-1)
Minimum int = -2147483648
Overflow of a long does not generate a trap
Maximum long = 2147483647 (= 2**31-1)
Minimum long = -2147483648
Maximum unsigned short = 65535
Maximum unsigned int = 4294967295
Maximum unsigned long = 4294967295
PROMOTIONS
unsigned short promotes to signed int/long
long+unsigned gives unsigned int/long
PROPERTIES OF FLOAT
Base = 2
Significant base digits = 24 (= at least 6 decimal digits)
Arithmetic rounds towards nearest
Tie breaking rounds to even
Smallest x such that 1.0-base**x != 1.0 = -24
Smallest x such that 1.0-x != 1.0 = 2.98023259e-08
Smallest x such that 1.0+base**x != 1.0 = -23
Smallest x such that 1.0+x != 1.0 = 5.96046519e-08
(Above number + 1.0) - 1.0 = 1.19209290e-07
Number of bits used for exponent = 8
Minimum normalised exponent = -126
Minimum normalised positive number = 1.17549435e-38
The smallest numbers are not kept normalised
Smallest unnormalised positive number = 1.40129846e-45
Maximum exponent = 128
Maximum number = 3.40282347e+38
Overflow doesn't seem to generate a trap
There is an 'infinite' value
Divide by zero doesn't generate a trap
Arithmetic uses a hidden bit
It looks like single length IEEE format
PROPERTIES OF DOUBLE
Base = 2
Significant base digits = 53 (= at least 15 decimal digits)
Arithmetic rounds towards nearest
Tie breaking rounds to even
Smallest x such that 1.0-base**x != 1.0 = -53
Smallest x such that 1.0-x != 1.0 = 5.5511151231257839e-17
Smallest x such that 1.0+base**x != 1.0 = -52
Smallest x such that 1.0+x != 1.0 = 1.1102230246251568e-16
(Above number + 1.0) - 1.0 = 2.2204460492503131e-16
Number of bits used for exponent = 11
Minimum normalised exponent = -1022
Minimum normalised positive number = 2.2250738585072014e-308
The smallest numbers are not kept normalised
Smallest unnormalised positive number = 4.9406564584124654e-324
Maximum exponent = 1024
Maximum number = 1.7976931348623157e+308
Overflow doesn't seem to generate a trap
There is an 'infinite' value
Divide by zero doesn't generate a trap
Arithmetic uses a hidden bit
It looks like double length IEEE format
Float expressions are evaluated in float precision
Double expressions are evaluated in double precision
Memory mallocatable ~= 241 Mbytes
FS1:\>
------------------------------------------------------------------------------
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
