public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Kinney, Michael D" <michael.d.kinney@intel.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	"Kinney, Michael D" <michael.d.kinney@intel.com>
Cc: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
	Laszlo Ersek <lersek@redhat.com>, Andrew Fish <afish@apple.com>
Subject: Re: [Patch] OvmfPkg: Add XCODE5 statements to fix build break
Date: Fri, 19 May 2017 17:24:46 +0000	[thread overview]
Message-ID: <E92EE9817A31E24EB0585FDF735412F57D175B7E@ORSMSX113.amr.corp.intel.com> (raw)
In-Reply-To: <CAKv+Gu-H+Y55APEEL422SCiDpDj1GmWJRotMq46nH77qptb8RA@mail.gmail.com>

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.biesheuvel@linaro.org]
> Sent: Friday, May 19, 2017 10:02 AM
> To: Kinney, Michael D <michael.d.kinney@intel.com>
> Cc: edk2-devel@lists.01.org; Laszlo Ersek <lersek@redhat.com>; Andrew Fish
> <afish@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.kinney@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.biesheuvel@linaro.org]
> >> Sent: Friday, May 19, 2017 1:32 AM
> >> To: Kinney, Michael D <michael.d.kinney@intel.com>
> >> Cc: edk2-devel@lists.01.org; Laszlo Ersek <lersek@redhat.com>; Andrew Fish
> >> <afish@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.kinney@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 <lersek@redhat.com>
> >> > Cc: Andrew Fish <afish@apple.com>
> >> > Contributed-under: TianoCore Contribution Agreement 1.0
> >> > Signed-off-by: Michael D Kinney <michael.d.kinney@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

      parent reply	other threads:[~2017-05-19 17:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-19  6:30 [Patch] OvmfPkg: Add XCODE5 statements to fix build break Michael Kinney
2017-05-19  8:21 ` Laszlo Ersek
2017-05-19  8:32 ` Ard Biesheuvel
2017-05-19 16:45   ` Kinney, Michael D
2017-05-19 17:02     ` Ard Biesheuvel
2017-05-19 17:15       ` Andrew Fish
2017-05-19 17:24       ` Kinney, Michael D [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E92EE9817A31E24EB0585FDF735412F57D175B7E@ORSMSX113.amr.corp.intel.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox