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 A1EB321B00DC1 for ; Mon, 27 Nov 2017 06:58:11 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 527B78553D; Mon, 27 Nov 2017 15:02:33 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-232.rdu2.redhat.com [10.10.120.232]) by smtp.corp.redhat.com (Postfix) with ESMTP id D0C591755C; Mon, 27 Nov 2017 15:02:31 +0000 (UTC) To: Ruiyu Ni References: <20171127013831.294104-1-ruiyu.ni@intel.com> Cc: edk2-devel@lists.01.org, "Zhu, Yonghong" , "Gao, Liming" , Ard Biesheuvel , "Jordan Justen (Intel address)" From: Laszlo Ersek Message-ID: <35fa258e-96ef-5dfb-cc06-287c3488a75b@redhat.com> Date: Mon, 27 Nov 2017 16:02:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171127013831.294104-1-ruiyu.ni@intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Mon, 27 Nov 2017 15:02:33 +0000 (UTC) Subject: Re: [PATCH] OvmfPkg/Sec: Fix 64bit SEC build failure X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 14:58:11 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Hi Ray, adding Ard, Jordan, Liming and Yonghong: On 11/27/17 02:38, Ruiyu Ni wrote: > Original code breaks a single assembly code to multiple lines. > But build tool doesn't support such usage in Windows OS environment. > > Changing the multiple lines to one line to resolve the build failure. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ruiyu Ni > Cc: Laszlo Ersek > --- > OvmfPkg/Sec/X64/SecEntry.nasm | 6 ++---- > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/OvmfPkg/Sec/X64/SecEntry.nasm b/OvmfPkg/Sec/X64/SecEntry.nasm > index 7c55032ac9..d76adcffd8 100644 > --- a/OvmfPkg/Sec/X64/SecEntry.nasm > +++ b/OvmfPkg/Sec/X64/SecEntry.nasm > @@ -45,10 +45,8 @@ ASM_PFX(_ModuleEntryPoint): > ; Fill the temporary RAM with the initial stack value. > ; The loop below will seed the heap as well, but that's harmless. > ; > - mov rax, (FixedPcdGet32 ( \ > - PcdInitValueInTempStack \ > - ) << 32) | \ > - FixedPcdGet32 (PcdInitValueInTempStack) ; qword to store > + mov rax, (FixedPcdGet32 (PcdInitValueInTempStack) << 32) | FixedPcdGet32 (PcdInitValueInTempStack) > + ; qword to store > mov rdi, FixedPcdGet32 (PcdOvmfSecPeiTempRamBase) ; base address, > ; relative to > ; ES > I'd like to understand more about the build failure. As far as I understand, the NASM tool itself has no problem with the backslash line continuation; before I posted the patch, I checked the NASM manual for this feature. http://www.nasm.us/doc/nasmdoc3.html#section-3.1 NASM uses backslash (\) as the line continuation character; if a line ends with backslash, the next line is considered to be a part of the backslash-ended line. Now, in "BaseTools/Conf/build_rule.template", I see that we have the following rule for NASM source files: [Nasm-Assembly-Code-File.COMMON.COMMON] ?.nasm $(MAKE_FILE) $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj "$(PP)" $(PP_FLAGS) $(INC) ${src} > ${d_path}(+)${s_base}.i Trim --trim-long --source-code -o ${d_path}(+)${s_base}.iii ${d_path}(+)${s_base}.i "$(NASM)" -I${s_path}(+) $(NASM_FLAGS) -o $dst ${d_path}(+)${s_base}.iii I guess it's actually the pre-processor (PP) that splices the broken-up lines together, as any C language pre-processor is supposed to do. Why does that not work with the VS toolchains ("cl.exe")? Is it perhaps a problem with the _PP_FLAGS? https://msdn.microsoft.com/en-us/library/3xkfswhy.aspx https://msdn.microsoft.com/en-us/library/032xwy55.aspx "/E" seems right (pre-process). Is /TC the problem? ("C language source code"). If the problem is impossible to fix in BaseTools, I don't mind the patch, but I'd like to see more explanation in the commit message. (Other assembly files use backslash line continuations too, they just haven't been exposed to VS toolchains yet, apparently.) Thanks Laszlo