Below is my Clang3.8 output. The Clang3.8 simply does not permit use mix use
_ms_va_list related builtins with System V ABI, only for Win64 ABI.
$ clang -flto -Wl,-Os ms_abi.c
ms_abi.c:19:3: error: '__builtin_ms_va_start' used in System V ABI function
VA_START (Marker, len);
^
ms_abi.c:6:38: note: expanded from macro 'VA_START'
#define VA_START(Marker, Parameter) __builtin_ms_va_start (Marker, Parameter)
^
1 error generated.
$ cat ms_abi.c
#include <stdio.h>
typedef __builtin_ms_va_list VA_LIST;
typedef unsigned long long UINTN;
#define VA_START(Marker, Parameter) __builtin_ms_va_start (Marker, Parameter)
#define VA_ARG(Marker, TYPE) ((sizeof (TYPE) < sizeof (UINTN)) ?
(TYPE)(__builtin_va_arg (Marker, UINTN)) : (TYPE)(__builtin_va_arg (Marker,
TYPE)))
#define VA_END(Marker) __builtin_ms_va_end (Marker)
#define VA_COPY(Dest, Start) __builtin_ms_va_copy (Dest, Start)
int EFI_printf(const int len, ...)
{
VA_LIST Marker;
int i;
VA_START (Marker, len);
for (i=0; i < len; i++) {
printf ("%d - %d\n", i, VA_ARG(Marker, int));
}
VA_END(Marker);
return len;
}
int
main ()
{
EFI_printf (8, 10, 11, 12, 12, 14, 15, 16, 17);
return 0;
}
BTW, if current XCODE has the ms_abi va_list issue, how the XCODE built X64
debug OVMF tip could really boot (it should hang when DEBUG print)? Does Mac
support qemu? If not, and if you need, I can help you to test it in my ubuntu.
Please build X64 debug OVMF tip with below command and send me the OVMF.fd.
build -a X64 -t XCODE -p OvmfPkg/OvmfPkgX64.dsc -n 5 -b DEBUG
-DDEBUG_ON_SERIAL_PORT
I usually test OVMF firmware with below command:
qemu-system-x86_64.exe -bios OVMF.fd -serial file:serial.log -m 512 -hda fat:.
Steven Shi
Intel\SSG\STO\UEFI Firmware
Tel: +86 021-61166522
iNet: 821-6522
> -----Original Message-----
> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Thursday, May 12, 2016 11:15 PM
> To: Shi, Steven <steven....@intel.com>
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] edk2 llvm branch
>
>
> > On May 12, 2016, at 7:51 AM, Shi, Steven <steven....@intel.com> wrote:
> >
> > Hi Andrew,
> > Below is my clang3.8 output:
> > $ clang --version
> > clang version 3.8.0 (tags/RELEASE_380/final)
> > Target: x86_64-unknown-linux-gnu
> > Thread model: posix
> > InstalledDir: /usr/local/bin
> >
> > $ clang -Os -flto ms_abi.c
> > ms_abi.c:19:3: error: 'va_start' used in Win64 ABI function
> > VA_START (Marker, len);
> > ^
> > ms_abi.c:6:38: note: expanded from macro 'VA_START'
> > #define VA_START(Marker, Parameter) __builtin_va_start (Marker,
> Parameter)
> > ^
> > 1 error generated.
> >
> > You can see the ms_abi va_list issue has been simply solved in LLVM3.8.
> Now both LLVM and GCC have a workaround to support va_list with MS ABI
> on x64 platform.
> >
> > Use
> > __builtin_ms_va_list ap;
> > __builtin_ms_va_start (ap, n);
> > __builtin_ms_va_end (ap);
> >
> > instead of
> >
> > __builtin_va_list ap;
> > __builtin_va_start (ap, n);
> > __builtin_va_end (ap);
> >
>
> Steven,
>
> I don't think that fixed the problem it moved the problem. Before int call
> (int
> a, ...) worked and __attribute__((ms_abi)) call (int a, ...) did not. I
> think you
> just flipped it so that int call (int a, ...) no longer works, but
> __attribute__((ms_abi)) call (int a, ...) does. That has the side effect of
> making the libs work as they are all EFIAPI. If an application/driver had an
> internal var arg function that was NOT EFIAPI it might fail?
>
> Try my example with your fix (__builtin_ms_va_start) but remove
> __attribute__((ms_abi)) and see if you get the correct answer.
>
> I'll ping our compiler team to see if there is a better answer.
>
> Thanks,
>
> Andrew Fish
>
> > In my current edk2 llvm branch, I've already use above workaround. See it
> in lines 494~502 of
> https://github.com/shijunjing/edk2/blob/llvm/MdePkg/Include/Base.h , and
> it works. You can see how I push to fix this issue in below links:
> > Clang: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093778.html
> > GCC: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50818
> > CLANG3.8 is better than GCC7.0 on this issue because CLANG3.8 will give a
> compiler error message like above to explicitly ban the va_list builtins with
> MS ABI, but GCC has no warning and continue to confuse user.
> >
> > Maybe XCode need sync the clang3.8 fix for the ms_abi va_list issue.
> >
> > Below is to apply the ms_va_list workaround in your code, and it looks
> work now.
> > $ cat ms_abi.c
> > #include <stdio.h>
> >
> > typedef __builtin_ms_va_list VA_LIST;
> > typedef unsigned long long UINTN;
> >
> > #define VA_START(Marker, Parameter) __builtin_ms_va_start (Marker,
> Parameter)
> >
> > #define VA_ARG(Marker, TYPE) ((sizeof (TYPE) < sizeof (UINTN)) ?
> (TYPE)(__builtin_va_arg (Marker, UINTN)) : (TYPE)(__builtin_va_arg (Marker,
> TYPE)))
> >
> > #define VA_END(Marker) __builtin_ms_va_end (Marker)
> >
> > #define VA_COPY(Dest, Start) __builtin_ms_va_copy (Dest, Start)
> >
> > __attribute__((ms_abi)) int EFI_printf(const int len, ...)
> > {
> > VA_LIST Marker;
> > int i;
> >
> > VA_START (Marker, len);
> > for (i=0; i < len; i++) {
> > printf ("%d - %d\n", i, VA_ARG(Marker, int));
> > }
> >
> > VA_END(Marker);
> > return len;
> > }
> >
> > int
> > main ()
> > {
> > EFI_printf (8, 10, 11, 12, 12, 14, 15, 16, 17);
> > return 0;
> > }
> >
> > $ clang -flto -Wl,-Os ms_abi.c
> > $ ./a.out
> > 0 - 10
> > 1 - 11
> > 2 - 12
> > 3 - 12
> > 4 - 14
> > 5 - 15
> > 6 - 16
> > 7 - 17
> >
> > So, I believe my current Clang3.8 LTO not stable issue is a new one, and I
> will continue to debug it. I will let you know if I make progress.
> >
> >
> > Steven Shi
> > Intel\SSG\STO\UEFI Firmware
> >
> > Tel: +86 021-61166522
> > iNet: 821-6522
> >
> >> -----Original Message-----
> >> From: af...@apple.com [mailto:af...@apple.com]
> >> Sent: Thursday, May 12, 2016 2:42 AM
> >> To: Shi, Steven <steven....@intel.com>
> >> Cc: edk2-devel@lists.01.org
> >> Subject: Re: [edk2] edk2 llvm branch
> >>
> >>
> >>> On May 11, 2016, at 9:38 AM, Shi, Steven <steven....@intel.com> wrote:
> >>>
> >>> Hi Andrew,
> >>>
> >>> Attachment and below are my build map files and code size for your
> >> suggested two modules with CLANGLTO38 and VS2013x86. Maybe I
> should
> >> use latest VS2015x86 for the comparing next time.
> >>>
> >>
> >> Steven,
> >>
> >> Thanks for the data.
> >>
> >>>
> >>>
> >>> * CLANGLTO38:
> >>>
> >>>> build -a IA32 -t CLANGLTO38 -p OvmfPkg/OvmfPkgIa32.dsc -n 5 -m
> >> IntelFrameworkModulePkg/Universal/StatusCode/Pei/StatusCodePei.inf -
> b
> >> RELEASE
> >>>
> >>> 1,184
> >>>
> >>>> build -a IA32 -t CLANGLTO38 -p OvmfPkg/OvmfPkgIa32.dsc -n 5 -m
> >> IntelFrameworkModulePkg/Universal/StatusCode/Pei/StatusCodePei.inf -
> b
> >> DEBUG -DDEBUG_ON_SERIAL_PORT
> >>>
> >>> 7,648
> >>>
> >>>> build -a X64 -t CLANGLTO38 -p OvmfPkg/OvmfPkgX64.dsc -n 5 -m
> >> PcAtChipsetPkg/8254TimerDxe/8254Timer.inf -b RELEASE
> >>>
> >>> 1,600
> >>>
> >>>> build -a X64 -t CLANGLTO38 -p OvmfPkg/OvmfPkgX64.dsc -n 5 -m
> >> PcAtChipsetPkg/8254TimerDxe/8254Timer.inf -b DEBUG -
> >> DDEBUG_ON_SERIAL_PORT
> >>>
> >>> 11,712 (with -fno-lto to disable lto in
> >> MdePkg\Library\BasePrintLib\BasePrintLib.inf, which is to work around
> CPU
> >> exception in PrintLib during boot time)
> >>>
> >>> 8,736 (with lto enalbed in BasePrintLib.inf)
> >>>
> >>>
> >>>
> >>> * VS2013x86:
> >>>
> >>>> build -a IA32 -t VS2013x86 -p OvmfPkg/OvmfPkgIa32.dsc -n 5 -m
> >> IntelFrameworkModulePkg/Universal/StatusCode/Pei/StatusCodePei.inf -
> b
> >> RELEASE
> >>>
> >>> 1,280
> >>>
> >>>> build -a IA32 -t VS2013x86 -p OvmfPkg/OvmfPkgIa32.dsc -n 5 -m
> >> IntelFrameworkModulePkg/Universal/StatusCode/Pei/StatusCodePei.inf -
> b
> >> DEBUG -DDEBUG_ON_SERIAL_PORT
> >>>
> >>> 8,576
> >>>
> >>>> build -a X64 -t VS2013x86 -p OvmfPkg/OvmfPkgX64.dsc -n 5 -m
> >> PcAtChipsetPkg/8254TimerDxe/8254Timer.inf -b RELEASE
> >>>
> >>> 1,760
> >>>
> >>>> build -a X64 -t VS2013x86 -p OvmfPkg/OvmfPkgX64.dsc -n 5 -m
> >> PcAtChipsetPkg/8254TimerDxe/8254Timer.inf -b DEBUG -
> >> DDEBUG_ON_SERIAL_PORT
> >>>
> >>> 9,760
> >>>
> >>>
> >>>
> >>> I believe the clang3.8 with LTO enabled is good enough on code size. My
> >> current biggest trouble is the Clang3.8 LTO not stable on GNU ld when
> >> generate X64 code, and worse on gold (even cannot finish build). I've
> >> reported two bugs about LTO against GNU ld and gold in below, FYI.
> >>>
> >>> https://sourceware.org/bugzilla/show_bug.cgi?id=20062
> >>>
> >>> https://sourceware.org/bugzilla/show_bug.cgi?id=20070
> >>>
> >>>
> >>
> >> Are those the linker command line failures? What about the code
> generation
> >> issues?
> >>
> >> On the code gen issues I would guess they have to do with
> >> __attribute__((ms_abi)) (call x86_64_win64cc in bit code)and var args.
> You
> >> might try building some simple examples at the command line and see if
> you
> >> can find an error. So for example you could write a simple Unix command
> >> line app to test calling a __attribute__((ms_abi)) var arg function that
> prints
> >> out information.
> >>
> >> What I usually do is try to make the simplest EFI case possible and then I
> >> locally define the EFI types. That makes it really easy to reproduce the
> issue
> >> for the compiler team.
> >>
> >> ~/work/Compiler>cat ms_abi.c
> >> #include <stdio.h>
> >>
> >> typedef __builtin_va_list VA_LIST;
> >> typedef unsigned long long UINTN;
> >>
> >> #define VA_START(Marker, Parameter) __builtin_va_start (Marker,
> >> Parameter)
> >>
> >> #define VA_ARG(Marker, TYPE) ((sizeof (TYPE) < sizeof (UINTN)) ?
> >> (TYPE)(__builtin_va_arg (Marker, UINTN)) : (TYPE)(__builtin_va_arg
> (Marker,
> >> TYPE)))
> >>
> >> #define VA_END(Marker) __builtin_va_end (Marker)
> >>
> >> #define VA_COPY(Dest, Start) __builtin_va_copy (Dest, Start)
> >>
> >> __attribute__((ms_abi)) int EFI_printf(const int len, ...)
> >> {
> >> VA_LIST Marker;
> >> int i;
> >>
> >> VA_START (Marker, len);
> >> for (i=0; i < len; i++) {
> >> printf ("%d - %d\n", i, VA_ARG(Marker, int));
> >> }
> >>
> >> VA_END(Marker);
> >> return len;
> >> }
> >>
> >> int
> >> main ()
> >> {
> >> EFI_printf (8, 10, 11, 12, 12, 14, 15, 16, 17);
> >> return 0;
> >> }~/work/Compiler>clang -Os -flto ms_abi.c
> >> ~/work/Compiler>./a.out
> >> 0 - 10
> >> 1 - 11
> >> 2 - 12
> >> 3 - 12
> >> 4 - 14
> >> 5 - 15
> >> 6 - 10
> >> 7 - 11
> >> ~/work/Compiler>
> >>
> >> Yikes I think I just reproduced your bug in the Xcode clang. Can you try
> >> this
> >> example on your toolchain and report the issue if you see it.
> >>
> >>>
> >>> BTW, does XCODE linker have linux version? If yes, I'd like to try it to
> >>> co-
> >> work with clang 3.8 as CC compiler.
> >>>
> >>>
> >>
> >> No it is Mac only, and only supports Mach-O not ELF. It is my
> understanding
> >> that the Xcode linker just links the bit code like normal (pulls in the
> symbols
> >> that are needed). Then this linked bit code blob is sent to an LLVM
> dynamic
> >> library to do the code gen. Maybe different version of LLVM are used by
> the
> >> different linkers in your case, or maybe the LLVM stuff is compiled in?
> >>
> >>
> >>
> >> Thanks,
> >>
> >> Andrew Fish
> >>
> >>>
> >>>
> >>>
> >>> Steven Shi
> >>>
> >>> Intel\SSG\STO\UEFI Firmware
> >>>
> >>>
> >>>
> >>> Tel: +86 021-61166522
> >>>
> >>> iNet: 821-6522
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>
> >>>> From: af...@apple.com [mailto:af...@apple.com]
> >>>
> >>>> Sent: Wednesday, May 11, 2016 11:09 PM
> >>>
> >>>> To: Shi, Steven <steven....@intel.com>
> >>>
> >>>> Cc: edk2-devel@lists.01.org
> >>>
> >>>> Subject: Re: [edk2] edk2 llvm branch
> >>>
> >>>>
> >>>
> >>>>
> >>>
> >>>>> On May 11, 2016, at 5:08 AM, Shi, Steven
> >> <steven....@intel.com<mailto:steven....@intel.com>> wrote:
> >>>
> >>>>>
> >>>
> >>>>> Hi Andrew,
> >>>
> >>>>> From your data, it looks the XCode LTO is not enabled correctly for
> IA32,
> >>>
> >>>> but correct for X64. Attachment has my build map files, and below are
> my
> >>>
> >>>> build commands. FYI.
> >>>
> >>>>>
> >>>
> >>>>
> >>>
> >>>> Sorry had a typo in the tools_def.txt, here are the numbers with -flto
> >>>
> >>>> correctly added to the CC_FLAGS:
> >>>
> >>>>
> >>>
> >>>>> build -a IA32 -t XCODE5 -p OvmfPkg/OvmfPkgIa32.dsc -n 5 -m
> >>>
> >>>> MdeModulePkg/Core/Pei/PeiMain.inf -b RELEASE
> >>>
> >>>> 25K
> >>>
> >>>>> build -a IA32 -t XCODE5 -p OvmfPkg/OvmfPkgIa32.dsc -n 5 -m
> >>>
> >>>> MdeModulePkg/Core/Pei/PeiMain.inf -b DEBUG -
> >>>
> >>>> DDEBUG_ON_SERIAL_PORT
> >>>
> >>>> 45K
> >>>
> >>>>> build -a X64 -t XCODE5 -p OvmfPkg/OvmfPkgX64.dsc -n 5 -m
> >>>
> >>>> MdeModulePkg/Core/Dxe/DxeMain.inf -b RELEASE
> >>>
> >>>> 103K
> >>>
> >>>>> build -a X64 -t XCODE5 -p OvmfPkg/OvmfPkgX64.dsc -n 5 -m
> >>>
> >>>> MdeModulePkg/Core/Dxe/DxeMain.inf -b DEBUG -
> >>>
> >>>> DDEBUG_ON_SERIAL_PORT
> >>>
> >>>> 133K
> >>>
> >>>>
> >>>
> >>>> When doing size optimizations it is often easier to start with smaller
> >> drivers.
> >>>
> >>>> Can you send the sizes/map files for:
> >>>
> >>>>> build -a IA32 -t XCODE5 -p OvmfPkg/OvmfPkgIa32.dsc -n 5 -m
> >>>
> >>>>
> IntelFrameworkModulePkg/Universal/StatusCode/Pei/StatusCodePei.inf -
> >> b
> >>>
> >>>> RELEASE
> >>>
> >>>> 1220
> >>>
> >>>>> build -a IA32 -t XCODE5 -p OvmfPkg/OvmfPkgIa32.dsc -n 5 -m
> >>>
> >>>>
> IntelFrameworkModulePkg/Universal/StatusCode/Pei/StatusCodePei.inf -
> >> b
> >>>
> >>>> DEBUG -DDEBUG_ON_SERIAL_PORT
> >>>
> >>>> 8228
> >>>
> >>>>> build -a X64 -t XCODE5 -p OvmfPkg/OvmfPkgX64.dsc -n 5 -m
> >>>
> >>>> PcAtChipsetPkg/8254TimerDxe/8254Timer.inf -b RELEASE
> >>>
> >>>> 2464
> >>>
> >>>>> build -a X64 -t XCODE5 -p OvmfPkg/OvmfPkgX64.dsc -n 5 -m
> >>>
> >>>> PcAtChipsetPkg/8254TimerDxe/8254Timer.inf -b DEBUG -
> >>>
> >>>> DDEBUG_ON_SERIAL_PORT
> >>>
> >>>> 9088
> >>>
> >>>>
> >>>
> >>>>
> >>>
> >>>>
> >>>
> >>>> I forgot to mention that X64 XCODE5/clang has a 5 byte overhead per
> >>>
> >>>> function vs.VS2013x86 due to supporting stack unwind. The upside is
> the
> >>>
> >>>> unexpected exception handler can print out a stack trace. VS2013x86
> >>>
> >>>> requires the debugger with symbols to unwind the stack.
> >>>
> >>>>
> >>>
> >>>> ~/work/Compiler>cat call.c
> >>>
> >>>> int main ()
> >>>
> >>>> {
> >>>
> >>>> return 0;
> >>>
> >>>> }
> >>>
> >>>> ~/work/Compiler>clang -Os call.c
> >>>
> >>>> ~/work/Compiler>lldb a.out
> >>>
> >>>> (lldb) target create "a.out"
> >>>
> >>>> Current executable set to 'a.out' (x86_64).
> >>>
> >>>> (lldb) dis -m -b -n main
> >>>
> >>>> a.out`main
> >>>
> >>>> a.out`main:
> >>>
> >>>> a.out[0x100000f98] <+0>: 55 pushq %rbp
> >>>
> >>>> a.out[0x100000f99] <+1>: 48 89 e5 movq %rsp, %rbp
> >>>
> >>>> a.out[0x100000f9c] <+4>: 31 c0 xorl %eax, %eax
> >>>
> >>>> a.out[0x100000f9e] <+6>: 5d popq %rbp
> >>>
> >>>> a.out[0x100000f9f] <+7>: c3 retq
> >>>
> >>>>
> >>>
> >>>> Thanks,
> >>>
> >>>>
> >>>
> >>>> Andrew Fish
> >>>
> >>>>
> >>>
> >>>>> VS2013x86:
> >>>
> >>>>> build -a IA32 -t VS2013x86 -p OvmfPkg\OvmfPkgIa32.dsc -n 5 -m
> >>>
> >>>> MdeModulePkg\Core\Pei\PeiMain.inf -b RELEASE
> >>>
> >>>>> build -a IA32 -t VS2013x86 -p OvmfPkg\OvmfPkgIa32.dsc -n 5 -m
> >>>
> >>>> MdeModulePkg\Core\Pei\PeiMain.inf -b DEBUG -
> >>>
> >>>> DDEBUG_ON_SERIAL_PORT
> >>>
> >>>>> build -a X64 -t VS2013x86 -p OvmfPkg\OvmfPkgX64.dsc -n 5 -m
> >>>
> >>>> MdeModulePkg\Core\Dxe\DxeMain.inf -b RELEASE
> >>>
> >>>>> build -a X64 -t VS2013x86 -p OvmfPkg\OvmfPkgX64.dsc -n 5 -m
> >>>
> >>>> MdeModulePkg\Core\Dxe\DxeMain.inf -b DEBUG -
> >>>
> >>>> DDEBUG_ON_SERIAL_PORT
> >>>
> >>>>>
> >>>
> >>>>> CLANGLTO38:
> >>>
> >>>>> build -a IA32 -t CLANGLTO38 -p OvmfPkg/OvmfPkgIa32.dsc -n 5 -m
> >>>
> >>>> MdeModulePkg/Core/Pei/PeiMain.inf -b RELEASE
> >>>
> >>>>> build -a IA32 -t CLANGLTO38 -p OvmfPkg/OvmfPkgIa32.dsc -n 5 -m
> >>>
> >>>> MdeModulePkg/Core/Pei/PeiMain.inf -b DEBUG -
> >>>
> >>>> DDEBUG_ON_SERIAL_PORT
> >>>
> >>>>> build -a X64 -t CLANGLTO38 -p OvmfPkg/OvmfPkgX64.dsc -n 5 -m
> >>>
> >>>> MdeModulePkg/Core/Dxe/DxeMain.inf -b RELEASE
> >>>
> >>>>> build -a X64 -t CLANGLTO38 -p OvmfPkg/OvmfPkgX64.dsc -n 5 -m
> >>>
> >>>> MdeModulePkg/Core/Dxe/DxeMain.inf -b DEBUG -
> >>>
> >>>> DDEBUG_ON_SERIAL_PORT
> >>>
> >>>>>
> >>>
> >>>>>
> >>>
> >>>>>
> >>>
> >>>>> Steven Shi
> >>>
> >>>>> Intel\SSG\STO\UEFI Firmware
> >>>
> >>>>>
> >>>
> >>>>> Tel: +86 021-61166522
> >>>
> >>>>> iNet: 821-6522
> >>>
> >>>>>
> >>>
> >>>>> From: af...@apple.com<mailto:af...@apple.com>
> >> [mailto:af...@apple.com]
> >>>
> >>>>> Sent: Wednesday, May 11, 2016 2:03 AM
> >>>
> >>>>> To: Shi, Steven <steven....@intel.com<mailto:steven....@intel.com>>
> >>>
> >>>>> Cc: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> >>>
> >>>>> Subject: Re: [edk2] edk2 llvm branch
> >>>
> >>>>>
> >>>
> >>>>>
> >>>
> >>>>> On May 10, 2016, at 8:05 AM, Shi, Steven
> >>>
> >>>>
> >>
> <steven....@intel.com<mailto:steven....@intel.com<mailto:steven.shi@int
> >> el.com%3cmailto:steven....@intel.com>>> wrote:
> >>>
> >>>>>
> >>>
> >>>>> Hi Andrew,
> >>>
> >>>>> Thank you for the suggestion. I will try your suggestion and response
> >> other
> >>>
> >>>> questions in your email later. I don't have XCODE5 environment, but
> could
> >> do
> >>>
> >>>> me a favor and let me know what current XCODE5 code size for
> >> PeiCore.efi
> >>>
> >>>> and DxeCore.efi in your side? In my side, as below data show, I see the
> >> LTO
> >>>
> >>>> can bring big code size improvement which is quite important for
> >> firmware in
> >>>
> >>>> many scenarios.
> >>>
> >>>>>
> >>>
> >>>>> I forgot to mention. LTO or not it is good to check to make sure the
> >>>
> >>>> assembly files are getting dead stripped. For example check to make
> sure
> >> you
> >>>
> >>>> are not getting all the assembly functions in the BaseLib included in
> your
> >>>
> >>>> executable. Some of the assembly is .S and some is .nasm so you may
> see
> >>>
> >>>> different behavior depending on which assembler was used.
> >>>
> >>>>>
> >>>
> >>>>> It is also useful to start looking at the smallest PEIM/DXE drivers 1st
> >>>>> as
> it
> >>>
> >>>> may be easier to spot what is different.
> >>>
> >>>>>
> >>>
> >>>>>
> >>>
> >>>>> Maybe it is also a good idea to enable LTO in XCODE.
> >>>
> >>>>>
> >>>
> >>>>> For Xcode you add -object_path_lto
> >>>
> >>>> $(DEST_DIR_DEBUG)/$(BASE_NAME).lto to
> *_XCODE5_*_DLINK_FLAGS.
> >>>
> >>>> This places the intermediate link code gen in the Build/ director vs. a
> temp
> >>>
> >>>> director and is important for source level debugging. To turn LTO on
> and
> >> off
> >>>
> >>>> you add -flto to *_XCODE5_*_CC_FLAGS .
> >>>
> >>>>>
> >>>
> >>>>> We ended up making LTO a configurable build option, so we control it
> in
> >>>
> >>>> the DSC file. git
> >>>
> >>>>>
> >>>
> >>>>> [BuildOptions]
> >>>
> >>>>> !if $(PEI_LTO_ENABLE)
> >>>
> >>>>> XCODE:*_*_IA32_PLATFORM_FLAGS = -flto
> >>>
> >>>>> !endif
> >>>
> >>>>>
> >>>
> >>>>> !if $(DXE_LTO_ENABLE)
> >>>
> >>>>> XCODE:*_*_X64_PLATFORM_FLAGS = -flto
> >>>
> >>>>> !endif
> >>>
> >>>>>
> >>>
> >>>>> I included the Xcode 6.3.2 Numbers:
> >>>
> >>>>>
> >>>
> >>>>>
> >>>
> >>>>>
> >>>
> >>>>>
> >>>
> >>>>> IA32 DEBUG PeiCore.efi on Ovmf build code size example:
> >>>
> >>>>> ToolChainName PeiCore.efi file size
> >>>
> >>>>> VS2013x86: 40KB
> >>>
> >>>>> CLANGLTO38: 42KB
> >>>
> >>>>> Xcode 61K
> >>>
> >>>>>
> >>>
> >>>>>
> >>>
> >>>>> GCCLTO53: 44KB
> >>>
> >>>>> GCC49: 55KB
> >>>
> >>>>> CLANG38: 60KB
> >>>
> >>>>>
> >>>
> >>>>>
> >>>
> >>>>> IA32 RELEASE PeiCore.efi on Ovmf build code size example:
> >>>
> >>>>> ToolChainName PeiCore.efi file size
> >>>
> >>>>> VS2013x86: 20KB
> >>>
> >>>>> GCCLTO53: 23KB
> >>>
> >>>>> CLANGLTO38: 24KB
> >>>
> >>>>> Xcode 31K
> >>>
> >>>>>
> >>>
> >>>>>
> >>>
> >>>>>
> >>>
> >>>>> GCC49: 27KB
> >>>
> >>>>> Clang38: 29KB
> >>>
> >>>>>
> >>>
> >>>>>
> >>>
> >>>>> X64 DEBUG DxeCore.efi on Ovmf build code size example:
> >>>
> >>>>> ToolChainName .efi file size LZMA
> >>>>> Compressed
> size
> >>>
> >>>>> VS2013x86: 137KB
> >>>>> 57KB
> >>>
> >>>>> CLANGLTO38: 145KB
> >>>>> 61KB
> >>>
> >>>>> Xcode 157K 68K
> >>>
> >>>>>
> >>>
> >>>>>
> >>>
> >>>>> GCCLTO53: 161KB
> >>>>> 63KB
> >>>
> >>>>> GCC49: 273KB 69KB
> >>>
> >>>>> CLANG38: 205KB
> >>>>> 72KB
> >>>
> >>>>>
> >>>
> >>>>>
> >>>
> >>>>>
> >>>
> >>>>> X64 RELEASE DxeCore.efi on Ovmf build code size example:
> >>>
> >>>>> ToolChainName .efi file size LZMA
> >>>>> Compressed
> size
> >>>
> >>>>> VS2013x86: 95KB
> >>>>> 44KB
> >>>
> >>>>> GCCLTO53: 101KB
> >>>>> 46KB
> >>>
> >>>>> CLANGLTO38: 107KB
> >>>>> 48KB
> >>>
> >>>>> Xcode 104K 49K
> >>>
> >>>>>
> >>>
> >>>>>
> >>>
> >>>>> GCC49: 184KB 52KB
> >>>
> >>>>> CLANG38: 133KB
> >>>>> 53KB
> >>>
> >>>>>
> >>>
> >>>>>
> >>>
> >>>>> Can you send my linker map files for VS2013 & CLANGLTO38 off list.
> >>>
> >>>>>
> >>>
> >>>>> Thanks,
> >>>
> >>>>>
> >>>
> >>>>> Andrew Fish
> >>>
> >>>>>
> >>>
> >>>>>
> >>>
> >>>>> Steven Shi
> >>>
> >>>>> Intel\SSG\STO\UEFI Firmware
> >>>
> >>>>>
> >>>
> >>>>> Tel: +86 021-61166522
> >>>
> >>>>> iNet: 821-6522
> >>>
> >>>>>
> >>>
> >>>>>> -----Original Message-----
> >>>
> >>>>>> From:
> >>
> af...@apple.com<mailto:af...@apple.com<mailto:af...@apple.com%3cmai
> >> lto:af...@apple.com>>
> >>>
> >>>> [mailto:af...@apple.com]
> >>>
> >>>>>> Sent: Tuesday, May 10, 2016 1:12 PM
> >>>
> >>>>>> To: Shi, Steven
> >>
> <steven....@intel.com<mailto:steven....@intel.com<mailto:steven.shi@int
> >> el.com%3cmailto:steven....@intel.com>>>
> >>>
> >>>>>> Cc: edk2-devel@lists.01.org<mailto:edk2-
> >> de...@lists.01.org<mailto:edk2-devel@lists.01.org%3cmailto:edk2-
> >> de...@lists.01.org>>
> >>>
> >>>>>> Subject: Re: [edk2] edk2 llvm branch
> >>>
> >>>>>>
> >>>
> >>>>>>
> >>>
> >>>>>
> >>>
> >>>>> _______________________________________________
> >>>
> >>>>> edk2-devel mailing list
> >>>
> >>>>> edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> >>>
> >>>>> https://lists.01.org/mailman/listinfo/edk2-devel
> >>>
> >>>
> >>> _______________________________________________
> >>> edk2-devel mailing list
> >>> edk2-devel@lists.01.org
> >>> https://lists.01.org/mailman/listinfo/edk2-devel
> >
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
