EDK2: Enable XCODE5 tool chain with NASM source

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

Posted by Liming Gao 6 years, 3 months ago

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.

Liming Gao (7):
  BaseTools: Disable -Wno-unused-const-variable in XCODE5 RELEASE target
  BaseTools: Use nasm as the preferred assembly source files for XCODE5
    tool
  MdeModulePkg: Update DebugSupportDxe to pass XCODE5 build
  UefiCpuPkg: Update CpuExceptionHandlerLib pass XCODE5 tool chain
  UefiCpuPkg: Update SmmCpuFeatureLib pass XCODE5 tool chain
  UefiCpuPkg: Update PiSmmCpuDxeSmm pass XCODE5 tool chain
  OvmfPkg: Don't add -mno-mmx -mno-sse option for XCODE5 tool chain

 BaseTools/Conf/tools_def.template                  |  7 ++--
 .../Universal/DebugSupportDxe/X64/AsmFuncs.nasm    |  6 ++--
 OvmfPkg/OvmfPkgIa32.dsc                            |  4 ++-
 OvmfPkg/OvmfPkgIa32X64.dsc                         |  4 ++-
 OvmfPkg/OvmfPkgX64.dsc                             |  4 ++-
 .../X64/ExceptionHandlerAsm.nasm                   | 29 +++++++++++----
 .../Library/SmmCpuFeaturesLib/Ia32/SmiEntry.nasm   |  6 +++-
 UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmStm.c      |  8 +++--
 UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmStm.h      | 11 +++++-
 .../Library/SmmCpuFeaturesLib/X64/SmiEntry.nasm    | 42 +++++++++++++++-------
 .../SmmCpuFeaturesLib/X64/SmiException.nasm        | 10 +++---
 UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c                  |  6 +++-
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.nasm       |  5 ++-
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmmInit.nasm        |  6 +++-
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c         |  8 ++++-
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h         | 20 ++++++++++-
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/MpFuncs.nasm         |  9 +++--
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.nasm        | 32 +++++++++++------
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiException.nasm    |  4 +--
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.nasm         | 17 +++++++--
 20 files changed, 174 insertions(+), 64 deletions(-)

-- 
2.11.0.windows.1

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

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

Posted by Laszlo Ersek 6 years, 3 months ago

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
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

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

Posted by Laszlo Ersek 6 years, 3 months ago

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

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

Posted by Gao, Liming 6 years, 3 months ago

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