Laszlo Ersek [mailto:ler...@redhat.com] wrote:
]On 10/29/14 05:59, Scott Duplichan wrote: ]> Optimization is not enabled for x64 builds using gcc 4.4-4.9. For IA32 ]> builds, -Os (optimize for small code size) is used. Why is this? Apparently ]> it is because variable argument list handling fails when gcc X64 optimization ]> is enabled. The solution is an improvement to the patch of SVN rev 10440: ]> http://sourceforge.net/p/edk2/mailman/message/25121111/ ] ]My reading of r10440 is different. As far as I understand, ] ] (gcc-4.4, X64, stdarg builtins) ] ]is simply a broken a combination, regardless of optimization. You are right about gcc X64 builds using the standard (native) stdarg builtins. Without the original r10440 patch, a test using Duet crashes early on. The exception handler dump has bogus values, probably due to the same stdarg problem. My point was why can't -Os be used for the current gcc X64 build like it is for the IA32 build? Maybe r10440 is not relevant enough to even be mentioned. What I found is adding -Os to the X64 Duet project causes the 'g' (GUID) format to malfunction. There may be other formatting problems, but this one is most obvious in the log file: X64 Duet boot log from gcc X64 build (standard, correct): WELCOME TO EFI WORLD! InstallProtocolInterface: D2B2B828-0826-48A7-B3DF-983C006024F0 1FDF9D58 HOBLIST address in DXE = 0x1F3DA018 Memory Allocation 0x00000004 0x1FD69000 - 0x1FD88FFF Memory Allocation 0x00000004 0x1F964000 - 0x1FD68FFF Memory Allocation 0x00000003 0x1FDB9000 - 0x1FE0FFFF FV Hob 0x1FE10000 - 0x1FFAFFFF InstallProtocolInterface: D8117CFE-94A6-11D4-9A3A-0090273FC14D 1FDF2AC0 InstallProtocolInterface: 8F644FA9-E850-4DB1-9CE2-0B44698E8DA4 1F3D6A30 InstallProtocolInterface: 09576E91-6D3F-11D2-8E39-00A0C969723B 1F3D7818 X64 Duet boot log from gcc X64 build (with -Os added): WELCOME TO EFI WORLD! InstallProtocolInterface: 00000000-30300000-332D3030-2D30303030 1FE6F8C0 HOBLIST address in DXE = 0x1F461018 Memory Allocation 0x00000004 0x1FDF0000 - 0x1FE0FFFF Memory Allocation 0x00000004 0x1F9EB000 - 0x1FDEFFFF Memory Allocation 0x00000003 0x1FE40000 - 0x1FE7FFFF FV Hob 0x1FE80000 - 0x1FFAFFFF InstallProtocolInterface: 1F9EAB08-46312000-342D3830-2D30303030 1FE69070 InstallProtocolInterface: 00000001-30300200-332D3130-2D30303230 1F45DA30 InstallProtocolInterface: 00000001-30308FA1-332D3130-2D31414630 1F45E818 If "-Os -mabi=ms" is used for the gcc X64 build, then the pre-r10440 method (using the native stdarg builtins) works. But that is just hiding the problem. The __builtin_ms_va_* macros for cross ABI use are not well documented as far as I can find. File cross-stdarg.h is about it. But they have been around for a long time, at least since gcc 4.4. Thanks, scott ]> The patch in this email only adds gcc X64 optimization for gcc versions 4.8 ]> and newer. ] ]What happens if you add -Os for gcc-4.8+ (X64) without touching ]NO_BUILTIN_VA_FUNCS and the VA_* macros? Just curious. See 'g' formatting problem above. ]What implies any connection between lack of -Os and VA_*? The fact that -Os is used throughout edk2, except for the one case where VA_* prevents it. ]Thanks! ]Laszlo ] ]> This is because testing with older versions of gcc is a lot of ]> work. On the other hand, the patch could be a lot simpler if it were to ]> ignore gcc version. The patch is boot tested using Duet with gcc 4.8.2 and ]> gcc 4.9.1. For these two cases, the print formatting problem is resolved ]> by the patch. ]> ]> Should we: ]> 1) Restrict the change to recent gcc versions where testing is easy ]> (approach of included patch) ]> 2) Apply the change to all gcc versions, and let older versions go ]> untested? ]> 3) Try to find/build the needed older gcc versions so that the patch ]> can apply to all versions and be tested too ]> ]> Thanks, ]> Scott ------------------------------------------------------------------------------ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
