Laszlo:
Thanks for comments. I submit two bugs. One is for UefiCpuPkg, another is for BaseTools.
https://bugzilla.tianocore.org/show_bug.cgi?id=849
https://bugzilla.tianocore.org/show_bug.cgi?id=850
> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Laszlo Ersek
> Sent: Thursday, January 11, 2018 6:03 PM
> To: Gao, Liming <liming.gao@intel.com>
> Cc: edk2-devel@lists.01.org; Andrew Fish <afish@apple.com>
> Subject: Re: [edk2] [Patch 0/7] EDK2: Enable XCODE5 tool chain with NASM source
>
> 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
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel