Re: [Patch 0/7] EDK2: Enable XCODE5 tool chain with NASM source

[Laszlo Ersek <lersek@redhat.com>]

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