From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from muon.cran.org.uk (muon.bluestop.org [IPv6:2605:7700:0:8:1:0:4a32:3323]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 5976A1A1E2A for ; Wed, 5 Oct 2016 16:04:35 -0700 (PDT) Received: from muon.bluestop.org (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 5030D94FEA; Wed, 5 Oct 2016 22:46:59 +0000 (UTC) Received: from muon.cran.org.uk ([127.0.0.1]) by muon.bluestop.org (muon.bluestop.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id IVAQO2gQCWNU; Wed, 5 Oct 2016 22:46:58 +0000 (UTC) Received: from [IPv6:2607:fb90:227c:331:1473:d4b1:83e0:185c] (unknown [IPv6:2607:fb90:227c:331:1473:d4b1:83e0:185c]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Wed, 5 Oct 2016 22:46:58 +0000 (UTC) Mime-Version: 1.0 (1.0) From: B Cran X-Mailer: iPhone Mail (14A456) In-Reply-To: Date: Wed, 5 Oct 2016 16:46:56 -0600 Cc: Laszlo Ersek , "edk2-devel@lists.01.org" , Liming Gao Message-Id: References: <1475631026-23928-1-git-send-email-yonghong.zhu@intel.com> <32c1e2a5-50e4-3152-0678-806f6bcc6bff@redhat.com> <5bb7f8e0-4b08-21dd-d236-dca106fcd9ac@redhat.com> To: Ard Biesheuvel Subject: Re: [Patch V2] BaseTools: support the NOOPT target with the GCC tool chains X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 23:04:35 -0000 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Tested-by: Bruce Cran > On Oct 5, 2016, at 12:06 PM, Ard Biesheuvel = wrote: >=20 >> On 5 October 2016 at 18:56, Laszlo Ersek wrote: >>> On 10/05/16 18:06, Ard Biesheuvel wrote: >>>> On 5 October 2016 at 15:48, Laszlo Ersek wrote: >>>>> On 10/05/16 03:30, Yonghong Zhu wrote: >>>>> Update the tools_def.template to add NOOPT support with GCC tool cha= ins. >>>>>=20 >>>>> Cc: Liming Gao >>>>> Cc: Laszlo Ersek >>>>> Contributed-under: TianoCore Contribution Agreement 1.0 >>>>> Signed-off-by: Yonghong Zhu >>>>> --- >>>>> BaseTools/Conf/tools_def.template | 28 ++++++++++++++++++++++++++++ >>>>> 1 file changed, 28 insertions(+) >>>>=20 >>>> I thought I understood what was going on, but apparently I was wrong >>>> about that. >>>>=20 >>>> In this patch, we add or modify: >>>> - NOOPT_*_*_OBJCOPY_ADDDEBUGFLAG -- okay >>>> - NOOPT_GCC*_(IA32|X64|ARM|AARCH64)_CC_FLAGS -- okay >>>>=20 >>>> So that part is fine with me. But then we also add / modify: >>>> - NOOPT_GCC(49|5)_AARCH64_DLINK_(FLAGS|XIPFLAGS) >>>> - NOOPT_GCC5_ARM_DLINK_FLAGS >>>>=20 >>>> First I thought the latter set of changes was unnecessary, because "l= d" >>>> didn't use "-O". I checked the manual, and I was wrong: "ld" does kno= w / >>>> use "-O". So those changes are fine, I guess. >>>>=20 >>>=20 >>> Yes, especially under LTO, in which case code generation is performed >>> during the link stage, which should adhere to the same rules as the >>> compiler. This not only applies to -O, but also to things like >>> -march/-mcpu and -mstrict-align. This is why we pass all CFLAGS to the >>> linker for the GCC5 LTO builds. >>>=20 >>>> But then: is the patch *complete*? Because I can see some more DLINK >>>> stuff, for IA32 and X64 (not just ARM and AARCH64). Is it okay to ign= ore >>>> those? For example: >>>>=20 >>>> *_GCC5_IA32_DLINK_FLAGS =3D DEF(GCC5_IA32_X64_DLINK_FLAGS) -= Os >>>> -Wl,-m,elf_i386,--oformat=3Delf32-i386 >>>>=20 >>>>=20 >>>> *_GCC5_X64_DLINK_FLAGS =3D DEF(GCC5_X64_DLINK_FLAGS) -Os >>>>=20 >>>> Where GCC5_X64_DLINK_FLAGS and GCC5_IA32_X64_DLINK_FLAGS even include >>>> -flto. (I don't know if "-flto" hampers source level debugging or not= .) >>>>=20 >>>=20 >>> The GCC man page documents -flto as being a bad idea, i.e., >>>=20 >>> """ >>> Link-time optimization does not work well with generation of debugging >>> information. Combining -flto with -g is currently experimental and >>> expected to produce unexpected results. >>> """ >>>=20 >>> (which raises a philosophical question as well, i.e., to which extent >>> expected unexpected results are still unexpected results. But I >>> digress ...) >>>=20 >>> Another note: the DEBUG build for ARM and AARCH64 is essentially NOOPT >>> already, not DEBUG. How does this patch intend to deal with that? >>=20 >> It just copies the DEBUG settings to NOOPT (via deep copy, not by >> reference). I believe that's OK. >>=20 >=20 > OK, fair enough. Leif and I can look into this in the future. > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel