From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 92D0B2205B905 for ; Thu, 11 Jan 2018 01:48:58 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1A666883A5; Thu, 11 Jan 2018 09:54:11 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-14.rdu2.redhat.com [10.10.120.14]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2A9DB60BE9; Thu, 11 Jan 2018 09:54:09 +0000 (UTC) To: Liming Gao References: <20180110152432.15964-1-liming.gao@intel.com> From: Laszlo Ersek Cc: edk2-devel@lists.01.org, Andrew Fish Message-ID: <25a13df1-e2f9-ce8e-e580-4905f8e45557@redhat.com> Date: Thu, 11 Jan 2018 10:54:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180110152432.15964-1-liming.gao@intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Thu, 11 Jan 2018 09:54:11 +0000 (UTC) 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: Thu, 11 Jan 2018 09:48:59 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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=TRUE > -DSECURE_BOOT_ENABLE=TRUE -DUSE_OLD_SHELL > build -p OvmfPkg\OvmfPkgIa32.dsc -a IA32 -a X64 -DSMM_REQUIRE=TRUE > -DSECURE_BOOT_ENABLE=TRUE -DUSE_OLD_SHELL > build -p OvmfPkg\OvmfPkgX64.dsc -a IA32 -a X64 -DSMM_REQUIRE=TRUE > -DSECURE_BOOT_ENABLE=TRUE -DUSE_OLD_SHELL > 4. Known limitation is XCODE5 doesn't support HII resource section generation. > So, new UEFI shell application tftp can't be used. Old shell is used. 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 nice 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 mode to long mode) could still be implemented in a human-readable assembly file. 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 in the next major release of XCODE -- I'm not sure). So a public bug report that we could reference in the commit messages would be great. Thanks! Laszlo