From: "gaoliming" <gaoliming@byosoft.com.cn>
To: "'Laszlo Ersek'" <lersek@redhat.com>, <devel@edk2.groups.io>
Cc: "'Sergei Dmitrouk'" <sergei@posteo.net>,
"'Bob Feng'" <bob.c.feng@intel.com>,
"'Ard Biesheuvel'" <ardb+tianocore@kernel.org>
Subject: 回复: [edk2-devel] [PATCH] BaseTools: Add -ffat-lto-objects option in GCC5 tool chain
Date: Thu, 20 May 2021 10:37:27 +0800 [thread overview]
Message-ID: <006701d74d21$130da5c0$3928f140$@byosoft.com.cn> (raw)
In-Reply-To: <4750f3f7-b558-e46d-4977-d8cd8ef24039@redhat.com>
Laszlo:
Here is the discussion https://edk2.groups.io/g/devel/message/75299.
Now, some uninitialized warning can't be detected on GCC5 tool chain, but can be detected on GCC49 tool chain.
Edk2 CI only covers GCC5 tool chain. So, the merged code may impact GCC49 build.
I add this option to expose such uninitialized warning in GCC5 tool chain and increase GCC5 tool chain coverage.
And, this is gcc issue https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90844
Yes. This change will expose some existing issues. I will include more detail in the commit message for this change.
Thanks
Liming
> -----邮件原件-----
> 发件人: Laszlo Ersek <lersek@redhat.com>
> 发送时间: 2021年5月19日 15:23
> 收件人: devel@edk2.groups.io; gaoliming@byosoft.com.cn
> 抄送: Sergei Dmitrouk <sergei@posteo.net>; Bob Feng
> <bob.c.feng@intel.com>; Ard Biesheuvel <ardb+tianocore@kernel.org>
> 主题: Re: [edk2-devel] [PATCH] BaseTools: Add -ffat-lto-objects option in
> GCC5 tool chain
>
> 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
> >
> >
next prev parent reply other threads:[~2021-05-20 2:37 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
2021-05-20 2:37 ` gaoliming [this message]
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='006701d74d21$130da5c0$3928f140$@byosoft.com.cn' \
--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