public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Roman Agafonov <Roman.Agafonov@aquantia.com>
To: "Gao, Liming" <liming.gao@intel.com>,
	"devel@edk2.groups.io" <devel@edk2.groups.io>
Cc: "Feng, Bob C" <bob.c.feng@intel.com>,
	"Zhu, Yonghong" <yonghong.zhu@intel.com>
Subject: Re: [PATCH v1 1/1] BaseTools: don't use WHOLEARCHIVE linker flag for VS2017 toolchain
Date: Thu, 6 Jun 2019 12:20:07 +0000	[thread overview]
Message-ID: <DM6PR11MB29553BA26FC48E13E22D4FCBEB170@DM6PR11MB2955.namprd11.prod.outlook.com> (raw)
In-Reply-To: <4A89E2EF3DFEDB4C8BFDE51014F606A14E46C5EF@SHSMSX104.ccr.corp.intel.com>

Hi Liming,

I don't have any custom options except a few ones to disable compiler warnings. AFAIK /GL is a compiler, not linker option, and it is used by EDK Visual Studio toolchains by default.

Of course, the results may vary from project to project. There difference may not be that big in all cases. Please try building some other package and compare the results. For example, this is what I get for OptionRomPkg compiled with two different toolchains. As you can see, the difference in size is abnormal.

pcfist@pcfist-pc:/mnt/c/src/UEFI/UDK2018/Build/OptionRomPkg$ ls -psh1 RELEASE_VS2017/X64 RELEASE_VS2015x86/X64
RELEASE_VS2015x86/X64:
total 212K
 20K AtapiPassThruDxe.efi
 24K AtapiPassThruDxe.rom
 28K Ax88772b.efi
 24K Ax88772.efi
 12K BltLibSample.efi
 24K CirrusLogic5430Dxe.efi
 12K CirrusLogic5430Dxe.rom
 24K FtdiUsbSerialDxe.efi
   0 MdePkg/
   0 OptionRomPkg/
8.0K TOOLS_DEF.X64
 36K UndiRuntimeDxe.efi

RELEASE_VS2017/X64:
total 424K
 56K AtapiPassThruDxe.efi
 56K AtapiPassThruDxe.rom
 60K Ax88772b.efi
 24K Ax88772.efi
 12K BltLibSample.efi
 56K CirrusLogic5430Dxe.efi
 28K CirrusLogic5430Dxe.rom
 56K FtdiUsbSerialDxe.efi
   0 MdePkg/
   0 OptionRomPkg/
8.0K TOOLS_DEF.X64
 68K UndiRuntimeDxe.efi

When comparing the .map files using difftool, I see a lot of unused functions from edk2 libraries (such as UefiDevicePathLib etc.) being included in the resulting executable, thus increasing its size. This is exactly what /WHOLEARCHIVE flag is intended for. My point here is whether this behavior is really desired, and given the fact that WHOLEARCHIVE had been removed from VS2015 toolchain previously, I don't see a reason to use it with VS2017 too.

Best regards,
Roman


From: Gao, Liming <liming.gao@intel.com>
Sent: Wednesday, June 5, 2019 6:47 PM
To: Roman Agafonov; devel@edk2.groups.io
Cc: Feng, Bob C; Zhu, Yonghong
Subject: RE: [PATCH v1 1/1] BaseTools: don't use WHOLEARCHIVE linker flag for VS2017 toolchain
 
I build edk2 OVMF with VS2015 and VS2017. Their image size are almost same. Have you the additional options to disable the optimization? In fact, /GL option will remove the unused function and logic.

> -----Original Message-----
> From: Roman Agafonov [mailto:Roman.Agafonov@aquantia.com]
> Sent: Wednesday, June 5, 2019 1:21 AM
> To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io
> Cc: Feng, Bob C <bob.c.feng@intel.com>; Zhu, Yonghong <yonghong.zhu@intel.com>
> Subject: Re: [PATCH v1 1/1] BaseTools: don't use WHOLEARCHIVE linker flag for VS2017 toolchain
>
> Hi Liming,
>
> Sure. Here is what I get after building our NIC driver binary with VS2015x86 and VS2017 toolchains:
>
> pcfist@pcfist-pc:/mnt/c/src/uefi/udk2018$ du -h Build/xgbe_atl/RELEASE_VS2015x86/X64/xgbe_atl.efi
> Build/xgbe_atl/RELEASE_VS2017/X64/xgbe_atl.efi
> 36K     Build/xgbe_atl/RELEASE_VS2015x86/X64/xgbe_atl.efi
> 68K     Build/xgbe_atl/RELEASE_VS2017/X64/xgbe_atl.efi
>
> Best regards,
> Roman
>
> From: Gao, Liming <liming.gao@intel.com>
> Sent: Tuesday, June 4, 2019 6:54 PM
> To: Roman Agafonov; devel@edk2.groups.io
> Cc: Feng, Bob C; Zhu, Yonghong
> Subject: RE: [PATCH v1 1/1] BaseTools: don't use WHOLEARCHIVE linker flag for VS2017 toolchain
>
> Can you show the size data with VS2017 and VS2015 for the same code?
>
> Thanks
> Liming
> > -----Original Message-----
> > From: Roman Agafonov [mailto:Roman.Agafonov@aquantia.com]
> > Sent: Tuesday, June 4, 2019 11:41 PM
> > To: devel@edk2.groups.io
> > Cc: Feng, Bob C <bob.c.feng@intel.com>; Gao, Liming <liming.gao@intel.com>; Zhu, Yonghong <yonghong.zhu@intel.com>
> > Subject: [PATCH v1 1/1] BaseTools: don't use WHOLEARCHIVE linker flag for VS2017 toolchain
> >
> > I have noticed the resulting binaries are about twice as large when
> > using VS2017 toolchain compared to the ones built with VS2015. It appears
> > this is caused by /WHOLEARCHIVE linker flag used by this toolchain. This
> > flag was previously removed from VS2015 toolchain due to compatibility
> > issues. I believe it should not be used with VS2017 as well.
> >
> > Cc: Bob Feng <bob.c.feng@intel.com>
> > Cc: Liming Gao <liming.gao@intel.com>
> > Cc: Yonghong Zhu <yonghong.zhu@intel.com>
> > Signed-off-by: Roman Agafonov <roman.agafonov@aquantia.com>
> > ---
> >  BaseTools/Conf/tools_def.template | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template
> > index 26a2cf604f74..482a526f3052 100755
> > --- a/BaseTools/Conf/tools_def.template
> > +++ b/BaseTools/Conf/tools_def.template
> > @@ -1545,7 +1545,7 @@ NOOPT_VS2015x86_X64_DLINK_FLAGS    = /NOLOGO /NODEFAULTLIB /IGNORE:4001 /OPT:REF
> >  *_VS2017_*_APP_FLAGS       = /nologo /E /TC
> >  *_VS2017_*_PP_FLAGS        = /nologo /E /TC /FIAutoGen.h
> >  *_VS2017_*_VFRPP_FLAGS     = /nologo /E /TC /DVFRCOMPILE /FI$(MODULE_NAME)StrDefs.h
> > -*_VS2017_*_DLINK2_FLAGS    = /WHOLEARCHIVE
> > +*_VS2017_*_DLINK2_FLAGS    =
> >  *_VS2017_*_ASM16_PATH      = DEF(VS2017_BIN_IA32)\ml.exe
> >
> >  ##################
> > --
> > 2.9.0.windows.1


  reply	other threads:[~2019-06-06 12:20 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-04 15:41 [PATCH v1 0/1] BaseTools: don't use WHOLEARCHIVE linker flag for VS2017 toolchain Roman Agafonov
2019-06-04 15:41 ` [PATCH v1 1/1] " Roman Agafonov
2019-06-04 15:54   ` Liming Gao
2019-06-04 17:20     ` Roman Agafonov
2019-06-05 15:47       ` Liming Gao
2019-06-06 12:20         ` Roman Agafonov [this message]
2019-06-06 14:06           ` Liming Gao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DM6PR11MB29553BA26FC48E13E22D4FCBEB170@DM6PR11MB2955.namprd11.prod.outlook.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox