Ard, The spec question is a good one. The statements from tools_def.txt that apply here are:
*_XCODE5_*_*_FAMILY = GCC *_XCODE5_*_*_BUILDRULEFAMILY = XCODE A build option statement may start with a FAMILY name or a BUILDRULEFAMILY name. If both are present, then statement that starts with the BUILDRULEFAMILY name is used instead of the FAMILY name. Table 8 in Section 5.2.3 of the EDK II Build Specification describe this behavior. https://edk2-docs.gitbooks.io/edk-ii-build-specification/content/5_meta-data_file_specifications/52_tools_def_txt.html#52-tools-deftxt BUILDRULEFAMILY This flag is used by some tool chain tags to set a special FAMILY value when processing the build_rule.txt file. Normally, the FAMILY attribute is used to identify the type of makefile the tools need to generate. Tools such as XCODE will use GCC as the FAMILY, but uses different (from GCC) processing rules. If present and if a build rule (in build_rules.txt) contains an attribute with the value specified in this entry, that rule will be processed and the rule with the FAMILY attribute will be ignored. However, the EDK II DSC Specification does not provide this same level of detail for the global [BuildOptions] and module specific <BuildOptions> sections. Please enter an issue against the EDK II DSC Specification if you think these additional descriptions are required. Thanks, Mike > -----Original Message----- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Friday, May 19, 2017 10:02 AM > To: Kinney, Michael D <michael.d.kin...@intel.com> > Cc: edk2-devel@lists.01.org; Laszlo Ersek <ler...@redhat.com>; Andrew Fish > <af...@apple.com> > Subject: Re: [edk2] [Patch] OvmfPkg: Add XCODE5 statements to fix build break > > On 19 May 2017 at 17:45, Kinney, Michael D <michael.d.kin...@intel.com> wrote: > > Hi Ard, > > > > The order of assignment does not matter. I have tried it > > both ways and both orders use the XCODE option instead of the > > GCC option when the XCODE5 tool chain is used. > > > > Interesting. Is this fully specified in any of the EDK2 specs? If not, > we are relying on an implementation detail of our BaseTools, which I > guess we'd rather avoid. > > > I have tried to adjust the XCODE family build flags to do 4KB > > alignment of PE/COFF sections for RT and SMM modules. This > > appears to work, but is not compatible firmware based page > > protections. Here are the flags I tried: > > > > XCODE:*_*_*_DLINK_FLAGS = -segalign 0x1000 -seg1addr 0x1000 > > XCODE:*_*_*_MTOC_FLAGS = -align 0x1000 > > > > I have not had a chance to root cause the reason why this > > is failing yet, so the initial fix here is to get XCODE5 > > to work without enabling 4KB alignment of RT and SMM > > modules. > > > > Fair enough. > > > I have entered a Bugzilla for the boot failure when I > > attempted to enable 4KB aligned PE/COFF images for the > > XCODE5 tool chain. > > > > https://bugzilla.tianocore.org/show_bug.cgi?id=564 > > > > Thanks, > > > > Mike > > > > > >> -----Original Message----- > >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > >> Sent: Friday, May 19, 2017 1:32 AM > >> To: Kinney, Michael D <michael.d.kin...@intel.com> > >> Cc: edk2-devel@lists.01.org; Laszlo Ersek <ler...@redhat.com>; Andrew Fish > >> <af...@apple.com> > >> Subject: Re: [edk2] [Patch] OvmfPkg: Add XCODE5 statements to fix build > >> break > >> > >> On 19 May 2017 at 07:30, Michael Kinney <michael.d.kin...@intel.com> wrote: > >> > https://bugzilla.tianocore.org/show_bug.cgi?id=559 > >> > > >> > The XCODE5 tool chain has a FAMILY of GCC. The > >> > GCC statements in the [BuildOptions] section add > >> > flags that are not compatible with XCODE5. Add > >> > empty XCODE5 statements in [BuildOptions] sections > >> > to prevent the use of the GCC flags in XCODE5 > >> > builds. > >> > > >> > Cc: Laszlo Ersek <ler...@redhat.com> > >> > Cc: Andrew Fish <af...@apple.com> > >> > Contributed-under: TianoCore Contribution Agreement 1.0 > >> > Signed-off-by: Michael D Kinney <michael.d.kin...@intel.com> > >> > >> Does XCODE not have a way to set the section alignment? This way, the > >> DXE memory protection and OS memory attribute table protection is > >> defeated. Also, does this rely on the order of assignment? > >> > >> > --- > >> > OvmfPkg/OvmfPkgIa32.dsc | 2 ++ > >> > OvmfPkg/OvmfPkgIa32X64.dsc | 2 ++ > >> > OvmfPkg/OvmfPkgX64.dsc | 2 ++ > >> > 3 files changed, 6 insertions(+) > >> > > >> > diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc > >> > index bd115c9..a0ea5db 100644 > >> > --- a/OvmfPkg/OvmfPkgIa32.dsc > >> > +++ b/OvmfPkg/OvmfPkgIa32.dsc > >> > @@ -75,11 +75,13 @@ > >> > > >> > [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER] > >> > GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000 > >> > + XCODE:*_*_*_DLINK_FLAGS = > >> > > >> > # Force PE/COFF sections to be aligned at 4KB boundaries to support > >> > page level > >> > # protection of DXE_SMM_DRIVER/SMM_CORE modules > >> > [BuildOptions.common.EDKII.DXE_SMM_DRIVER, > >> > BuildOptions.common.EDKII.SMM_CORE] > >> > GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000 > >> > + XCODE:*_*_*_DLINK_FLAGS = > >> > > >> > > >> > ################################################################################ > >> > # > >> > diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc > >> > index 9727db8..9ab58aa 100644 > >> > --- a/OvmfPkg/OvmfPkgIa32X64.dsc > >> > +++ b/OvmfPkg/OvmfPkgIa32X64.dsc > >> > @@ -80,11 +80,13 @@ > >> > > >> > [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER] > >> > GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000 > >> > + XCODE:*_*_*_DLINK_FLAGS = > >> > > >> > # Force PE/COFF sections to be aligned at 4KB boundaries to support > >> > page level > >> > # protection of DXE_SMM_DRIVER/SMM_CORE modules > >> > [BuildOptions.common.EDKII.DXE_SMM_DRIVER, > >> > BuildOptions.common.EDKII.SMM_CORE] > >> > GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000 > >> > + XCODE:*_*_*_DLINK_FLAGS = > >> > > >> > > >> > ################################################################################ > >> > # > >> > diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc > >> > index 61aaed7..88060cd 100644 > >> > --- a/OvmfPkg/OvmfPkgX64.dsc > >> > +++ b/OvmfPkg/OvmfPkgX64.dsc > >> > @@ -80,11 +80,13 @@ > >> > > >> > [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER] > >> > GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000 > >> > + XCODE:*_*_*_DLINK_FLAGS = > >> > > >> > # Force PE/COFF sections to be aligned at 4KB boundaries to support > >> > page level > >> > # protection of DXE_SMM_DRIVER/SMM_CORE modules > >> > [BuildOptions.common.EDKII.DXE_SMM_DRIVER, > >> > BuildOptions.common.EDKII.SMM_CORE] > >> > GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000 > >> > + XCODE:*_*_*_DLINK_FLAGS = > >> > > >> > > >> > ################################################################################ > >> > # > >> > -- > >> > 2.6.3.windows.1 > >> > > >> > _______________________________________________ > >> > 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
