From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=192.55.52.115; helo=mga14.intel.com; envelope-from=liming.gao@intel.com; receiver=edk2-devel@lists.01.org Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) (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 BF51D2205B92C for ; Thu, 11 Jan 2018 18:10:00 -0800 (PST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jan 2018 18:15:14 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,347,1511856000"; d="scan'208";a="8996255" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by fmsmga007.fm.intel.com with ESMTP; 11 Jan 2018 18:15:14 -0800 Received: from FMSMSX110.amr.corp.intel.com (10.18.116.10) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 11 Jan 2018 18:15:14 -0800 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by fmsmsx110.amr.corp.intel.com (10.18.116.10) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 11 Jan 2018 18:15:13 -0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.152]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.218]) with mapi id 14.03.0319.002; Fri, 12 Jan 2018 10:15:12 +0800 From: "Gao, Liming" To: Laszlo Ersek CC: "edk2-devel@lists.01.org" , Andrew Fish Thread-Topic: [edk2] [Patch 0/7] EDK2: Enable XCODE5 tool chain with NASM source Thread-Index: AQHTiid3By+/gKCmGUePZpdFvRv4JKNt6dSAgAACcYCAAZVNoA== Date: Fri, 12 Jan 2018 02:15:11 +0000 Message-ID: <4A89E2EF3DFEDB4C8BFDE51014F606A14E1A3B47@SHSMSX104.ccr.corp.intel.com> References: <20180110152432.15964-1-liming.gao@intel.com> <25a13df1-e2f9-ce8e-e580-4905f8e45557@redhat.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: Re: [Patch 0/7] EDK2: Enable XCODE5 tool chain with NASM source X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 02:10:01 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Laszlo: Thanks for comments. I submit two bugs. One is for UefiCpuPkg, another is= for BaseTools.=20 https://bugzilla.tianocore.org/show_bug.cgi?id=3D849 https://bugzilla.tianocore.org/show_bug.cgi?id=3D850 > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of La= szlo Ersek > Sent: Thursday, January 11, 2018 6:03 PM > To: Gao, Liming > Cc: edk2-devel@lists.01.org; Andrew Fish > Subject: Re: [edk2] [Patch 0/7] EDK2: Enable XCODE5 tool chain with NASM = source >=20 > On 01/11/18 10:54, Laszlo Ersek wrote: > > Liming, > > > > On 01/10/18 16:24, Liming Gao wrote: > >> 1. Use nasm source file for X86 tool chain, then ASM and S file can be= removed. > >> 2. Update Nasm source file to resolve the absolute addressing. > >> 3. Verify OVMF IA32, IA32X64 and X64 boot to shell functionality with = XCODE5 > >> Here is build command. > >> build -p OvmfPkg\OvmfPkgIa32X64.dsc -a IA32 -a X64 -DSMM_REQUIRE=3D= TRUE > >> -DSECURE_BOOT_ENABLE=3DTRUE -DUSE_OLD_SHELL > >> build -p OvmfPkg\OvmfPkgIa32.dsc -a IA32 -a X64 -DSMM_REQUIRE=3DTRU= E > >> -DSECURE_BOOT_ENABLE=3DTRUE -DUSE_OLD_SHELL > >> build -p OvmfPkg\OvmfPkgX64.dsc -a IA32 -a X64 -DSMM_REQUIRE=3DTRUE > >> -DSECURE_BOOT_ENABLE=3DTRUE -DUSE_OLD_SHELL > >> 4. Known limitation is XCODE5 doesn't support HII resource section gen= eration. > >> So, new UEFI shell application tftp can't be used. Old shell is use= d. > > > > After sleeping on this, I got a question: is there a public bug report > > in the clang / llvm bug tracker about this shortcoming? It would be nic= e > > to reference it in the commit messages. > > > > The main reason I'm asking this is because these workarounds include > > more and more DB / DW / DD / DQ mnemonics in the NASM source files. One > > of the original promises of NASM was that we could cut down on the > > binary representation of x86 instructions, just write real assembly > > code. This was in part enabled by NASM supporting multi-mode assembly > > files, such that mode transitions (e.g. from real mode to protected mod= e > > to long mode) could still be implemented in a human-readable assembly f= ile. > > > > So this workaround is a step back in that regard (i.e., for readability > > and future updates). I agree we are sometimes forced to do such things > > to support all the toolchains we target, but it would be nice to have > > proof that the clang / llvm developers *intend* to fix this (possibly i= n > > the next major release of XCODE -- I'm not sure). So a public bug repor= t > > that we could reference in the commit messages would be great. >=20 > Nevermind, I just read Mike's comments and the new approach; it's much > better! >=20 > (Still, if we have an XCODE bug report, it would be nice to reference > that in the commit messages.) >=20 > Thanks! > Laszlo > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel