public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Laszlo Ersek" <lersek@redhat.com>
To: gaoliming <gaoliming@byosoft.com.cn>, devel@edk2.groups.io
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: Thu, 20 May 2021 09:27:24 +0200	[thread overview]
Message-ID: <82b59f06-8b89-07cc-b426-fde56247389b@redhat.com> (raw)
In-Reply-To: <006701d74d21$130da5c0$3928f140$@byosoft.com.cn>

On 05/20/21 04:37, gaoliming wrote:
> 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.  

Great, thanks for the info.

Can you please include the reference

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90844

in the commit message?

Acked-by: Laszlo Ersek <lersek@redhat.com>

Thanks!
Laszlo

> 
> 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
>>>
>>>
> 
> 
> 


  reply	other threads:[~2021-05-20  7:27 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
2021-05-20  7:27     ` Laszlo Ersek [this message]
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=82b59f06-8b89-07cc-b426-fde56247389b@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