public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Laszlo Ersek" <lersek@redhat.com>
To: devel@edk2.groups.io, gaoliming@byosoft.com.cn
Cc: Sergei Dmitrouk <sergei@posteo.net>,
	Bob Feng <bob.c.feng@intel.com>,
	Ard Biesheuvel <ardb+tianocore@kernel.org>
Subject: Re: [edk2-devel] [PATCH] BaseTools: Add -ffat-lto-objects option in GCC5 tool chain
Date: Wed, 19 May 2021 09:23:19 +0200	[thread overview]
Message-ID: <4750f3f7-b558-e46d-4977-d8cd8ef24039@redhat.com> (raw)
In-Reply-To: <20210519022704.309-1-gaoliming@byosoft.com.cn>

Hi Liming,

On 05/19/21 04:27, gaoliming wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3403
> 
> This option can trig the uninitialized warning when lto is enabled.
> The image size data is also collected for OVMF. There is no impact.
> 
> Cc: Sergei Dmitrouk <sergei@posteo.net>
> Cc: Bob Feng <bob.c.feng@intel.com>
> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
> Signed-off-by: Liming Gao <gaoliming@byosoft.com.cn>
> ---
>  BaseTools/Conf/tools_def.template | 16 ++++++++--------
>  1 file changed, 8 insertions(+), 8 deletions(-)

I've now read the documentation on "-ffat-lto-objects", and I agree that
it should not affect the final module executable sizes.

However, I don't understand how this option *helps*. You mention
"uninitialized warning". I find nothing related to that in the
documentation.

According to the documentation, "fat" LTO objects include both object
code and intermediate language (GIMPLE) bytecode. Such objects can then
be linked with, or without, link-time (= interprocedural) optimization.
As I understand the documentation, "fat" LTO objects only make a
difference if there are parts of the toolchain that are themselves
unaware of LTO, and so need the GIMPLE bytecode to be present in the
object files.

I *guess* that this is the situation that we have in edk2 -- is there
perhaps something in our toolchain(s) that does not "notice" LTO without
"fat" LTO objects, and therefore we fail to emit a warning? Because,
without LTO, we don't notice that an initialization is missing?

This is too speculative. The commit message should please include more
details. I'd like to understand what code in edk2 is affected, what the
specific warning is, what the problematic component in the toolchain is
(i.e., what tool requires GIMPLE bytecode to be present in the object file).

Thanks,
Laszlo



> 
> diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template
> index 498696e583..aad5297385 100755
> --- a/BaseTools/Conf/tools_def.template
> +++ b/BaseTools/Conf/tools_def.template
> @@ -2315,10 +2315,10 @@ RELEASE_GCC49_AARCH64_DLINK_XIPFLAGS = -z common-page-size=0x20
>  *_GCC5_IA32_OBJCOPY_FLAGS        =
>  *_GCC5_IA32_NASM_FLAGS           = -f elf32
>  
> -  DEBUG_GCC5_IA32_CC_FLAGS       = DEF(GCC5_IA32_CC_FLAGS) -flto -Os
> +  DEBUG_GCC5_IA32_CC_FLAGS       = DEF(GCC5_IA32_CC_FLAGS) -ffat-lto-objects -flto -Os
>    DEBUG_GCC5_IA32_DLINK_FLAGS    = DEF(GCC5_IA32_X64_DLINK_FLAGS) -flto -Os -Wl,-m,elf_i386,--oformat=elf32-i386
>  
> -RELEASE_GCC5_IA32_CC_FLAGS       = DEF(GCC5_IA32_CC_FLAGS) -flto -Os -Wno-unused-but-set-variable -Wno-unused-const-variable
> +RELEASE_GCC5_IA32_CC_FLAGS       = DEF(GCC5_IA32_CC_FLAGS) -ffat-lto-objects -flto -Os -Wno-unused-but-set-variable -Wno-unused-const-variable
>  RELEASE_GCC5_IA32_DLINK_FLAGS    = DEF(GCC5_IA32_X64_DLINK_FLAGS) -flto -Os -Wl,-m,elf_i386,--oformat=elf32-i386
>  
>    NOOPT_GCC5_IA32_CC_FLAGS       = DEF(GCC5_IA32_CC_FLAGS) -O0
> @@ -2347,10 +2347,10 @@ RELEASE_GCC5_IA32_DLINK_FLAGS    = DEF(GCC5_IA32_X64_DLINK_FLAGS) -flto -Os -Wl,
>  *_GCC5_X64_OBJCOPY_FLAGS         =
>  *_GCC5_X64_NASM_FLAGS            = -f elf64
>  
> -  DEBUG_GCC5_X64_CC_FLAGS        = DEF(GCC5_X64_CC_FLAGS) -flto -DUSING_LTO -Os
> +  DEBUG_GCC5_X64_CC_FLAGS        = DEF(GCC5_X64_CC_FLAGS) -ffat-lto-objects -flto -DUSING_LTO -Os
>    DEBUG_GCC5_X64_DLINK_FLAGS     = DEF(GCC5_X64_DLINK_FLAGS) -flto -Os
>  
> -RELEASE_GCC5_X64_CC_FLAGS        = DEF(GCC5_X64_CC_FLAGS) -flto -DUSING_LTO -Os -Wno-unused-but-set-variable -Wno-unused-const-variable
> +RELEASE_GCC5_X64_CC_FLAGS        = DEF(GCC5_X64_CC_FLAGS) -ffat-lto-objects -flto -DUSING_LTO -Os -Wno-unused-but-set-variable -Wno-unused-const-variable
>  RELEASE_GCC5_X64_DLINK_FLAGS     = DEF(GCC5_X64_DLINK_FLAGS) -flto -Os
>  
>    NOOPT_GCC5_X64_CC_FLAGS        = DEF(GCC5_X64_CC_FLAGS) -O0
> @@ -2382,10 +2382,10 @@ RELEASE_GCC5_X64_DLINK_FLAGS     = DEF(GCC5_X64_DLINK_FLAGS) -flto -Os
>  *_GCC5_ARM_VFRPP_FLAGS           = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) DEF(GCC_VFRPP_FLAGS)
>  *_GCC5_ARM_CC_XIPFLAGS           = DEF(GCC5_ARM_CC_XIPFLAGS)
>  
> -  DEBUG_GCC5_ARM_CC_FLAGS        = DEF(GCC5_ARM_CC_FLAGS) -flto -Wno-unused-but-set-variable -Wno-unused-const-variable
> +  DEBUG_GCC5_ARM_CC_FLAGS        = DEF(GCC5_ARM_CC_FLAGS) -ffat-lto-objects -flto -Wno-unused-but-set-variable -Wno-unused-const-variable
>    DEBUG_GCC5_ARM_DLINK_FLAGS     = DEF(GCC5_ARM_DLINK_FLAGS) -flto -Os -L$(WORKSPACE)/ArmPkg/Library/GccLto -llto-arm -Wl,-plugin-opt=-pass-through=-llto-arm
>  
> -RELEASE_GCC5_ARM_CC_FLAGS        = DEF(GCC5_ARM_CC_FLAGS) -flto -Wno-unused-but-set-variable -Wno-unused-const-variable
> +RELEASE_GCC5_ARM_CC_FLAGS        = DEF(GCC5_ARM_CC_FLAGS) -ffat-lto-objects -flto -Wno-unused-but-set-variable -Wno-unused-const-variable
>  RELEASE_GCC5_ARM_DLINK_FLAGS     = DEF(GCC5_ARM_DLINK_FLAGS) -flto -Os -L$(WORKSPACE)/ArmPkg/Library/GccLto -llto-arm -Wl,-plugin-opt=-pass-through=-llto-arm
>  
>    NOOPT_GCC5_ARM_CC_FLAGS        = DEF(GCC5_ARM_CC_FLAGS) -O0
> @@ -2416,11 +2416,11 @@ RELEASE_GCC5_ARM_DLINK_FLAGS     = DEF(GCC5_ARM_DLINK_FLAGS) -flto -Os -L$(WORKS
>  *_GCC5_AARCH64_VFRPP_FLAGS       = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) DEF(GCC_VFRPP_FLAGS)
>  *_GCC5_AARCH64_CC_XIPFLAGS       = DEF(GCC5_AARCH64_CC_XIPFLAGS)
>  
> -  DEBUG_GCC5_AARCH64_CC_FLAGS    = DEF(GCC5_AARCH64_CC_FLAGS) -flto -Wno-unused-but-set-variable -Wno-unused-const-variable
> +  DEBUG_GCC5_AARCH64_CC_FLAGS    = DEF(GCC5_AARCH64_CC_FLAGS) -ffat-lto-objects -flto -Wno-unused-but-set-variable -Wno-unused-const-variable
>    DEBUG_GCC5_AARCH64_DLINK_FLAGS = DEF(GCC5_AARCH64_DLINK_FLAGS) -flto -Os -L$(WORKSPACE)/ArmPkg/Library/GccLto -llto-aarch64 -Wl,-plugin-opt=-pass-through=-llto-aarch64 -Wno-lto-type-mismatch
>    DEBUG_GCC5_AARCH64_DLINK_XIPFLAGS = -z common-page-size=0x20
>  
> -RELEASE_GCC5_AARCH64_CC_FLAGS    = DEF(GCC5_AARCH64_CC_FLAGS) -flto -Wno-unused-but-set-variable -Wno-unused-const-variable
> +RELEASE_GCC5_AARCH64_CC_FLAGS    = DEF(GCC5_AARCH64_CC_FLAGS) -ffat-lto-objects -flto -Wno-unused-but-set-variable -Wno-unused-const-variable
>  RELEASE_GCC5_AARCH64_DLINK_FLAGS = DEF(GCC5_AARCH64_DLINK_FLAGS) -flto -Os -L$(WORKSPACE)/ArmPkg/Library/GccLto -llto-aarch64 -Wl,-plugin-opt=-pass-through=-llto-aarch64 -Wno-lto-type-mismatch
>  RELEASE_GCC5_AARCH64_DLINK_XIPFLAGS = -z common-page-size=0x20
>  
> 


  parent reply	other threads:[~2021-05-19  7:23 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-19  2:27 [PATCH] BaseTools: Add -ffat-lto-objects option in GCC5 tool chain gaoliming
2021-05-19  2:35 ` [edk2-devel] " Yao, Jiewen
2021-05-19  2:51   ` 回复: " gaoliming
2021-05-19  7:23 ` Laszlo Ersek [this message]
2021-05-20  2:37   ` gaoliming
2021-05-20  7:27     ` Laszlo Ersek
2021-05-21  5:07       ` 回复: " gaoliming

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=4750f3f7-b558-e46d-4977-d8cd8ef24039@redhat.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