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=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.
Nevermind, I just read Mike's comments and the new approach; it's much better! (Still, if we have an XCODE bug report, it would be nice to reference that in the commit messages.) Thanks! Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel