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

[Laszlo Ersek <lersek@redhat.com>]

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