Hi, yesterday I set up a VS2015x86 toolchain for test-building OVMF. I also resurrected my Fedora virtual machines that are dedicated to test-building OVMF with GCC44-GCC49 toolchains.
I've found some C language build errors already, and I'm progressing through them slowly. However, one "killer" problem is the following NASM failure (emitted by nasm-2.07-4.fc13.x86_64; that is, in my Fedora 13 guest): > UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:173: > error: invalid combination of opcode and operands > UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:175: > error: invalid combination of opcode and operands > UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:177: > error: invalid combination of opcode and operands > UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:179: > error: invalid combination of opcode and operands > UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:313: > error: invalid combination of opcode and operands > UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:315: > error: invalid combination of opcode and operands This is the code in question: 168 ;; UINT64 Gs, Fs, Es, Ds, Cs, Ss; insure high 16 bits of each is zero 169 movzx rax, word [rbp + 56] 170 push rax ; for ss 171 movzx rax, word [rbp + 32] 172 push rax ; for cs 173 mov rax, ds 174 push rax 175 mov rax, es 176 push rax 177 mov rax, fs 178 push rax 179 mov rax, gs 180 push rax 181 182 mov [rbp + 8], rcx ; save vector number and 306 ;; UINT64 Gs, Fs, Es, Ds, Cs, Ss; 307 pop rax 308 ; mov gs, rax ; not for gs 309 pop rax 310 ; mov fs, rax ; not for fs 311 ; (X64 will not use fs and gs, so we do not restore it) 312 pop rax 313 mov es, rax 314 pop rax 315 mov ds, rax 316 pop qword [rbp + 32] ; for cs 317 pop qword [rbp + 56] ; for ss The problem is that NASM wouldn't support segment register MOVs in 64-bit mode until the following commit: http://repo.or.cz/nasm.git/commitdiff/21d4ccc3c338 Wed, 25 Aug 2010 02:28:00 +0200 (24 17:28 -0700) However, that change was first released in NASM 2.10: http://repo.or.cz/nasm.git/commitdiff/ff62f33da0a2 Mon, 12 Mar 2012 21:36:02 +0100 (12 13:36 -0700) I tried to work around this; for example by using movzx eax, ds with the idea that: - the upper 16 bits of EAX would be cleared by MOVZX, and - the upper 32-bits of RAX would be automatically cleared by any write to EAX. Unfortunately, this fails the exact same way. Now, I checked out the nasm source tree at tag "nasm-2.07" exactly, and checked the "insns.dat" file (the file that the above commit, 21d4ccc3c338, extends), searching it for "reg_sreg". I wanted to see if there was any other (i.e., non-MOV) way, supported by nasm-2.07, for accessing segment registers. I only found RSDC ("Restore Register and Descriptor") and SVDC ("Save Register and Descriptor"). Those instructions seem to be vendor extensions; they are not in the Intel SDM. It seems that before NASM 2.10, there's simply no way to access segment registers in 64-bit mode. I propose that we upgrade the following comment in BaseTools: > diff --git a/BaseTools/Conf/tools_def.template > b/BaseTools/Conf/tools_def.template > index 2065fa34998f..db61a37b6afd 100644 > --- a/BaseTools/Conf/tools_def.template > +++ b/BaseTools/Conf/tools_def.template > @@ -708,7 +708,7 @@ DEFINE SOURCERY_CYGWIN_TOOLS = /cygdrive/c/Program > Files/CodeSourcery/Sourcery G > # > # Other Supported Tools > # ===================== > -# NASM 2.07 or later http://www.nasm.us/ > +# NASM 2.10 or later http://www.nasm.us/ > # > > #################################################################################### > > #################################################################################### plus wherever the minimum NASM version is documented on the Wiki. Thanks Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
